2012-08-01
[19:51:30.0000] <Hixie>
hober: i think relaxed="" is a terrible idea (presumably its presence is still non-conforming, just as the lack of alt="" is non-conforming today even in the presence of <meta>), but what would stop an author from using it instead of alt="" by mistake? (e.g. through cargo culting)

[19:52:14.0000] <Hixie>
er, s/<meta>)/<meta>/ and s/culting)/culting))/

[19:52:32.0000] <Hixie>
hober: but, if we're going to have it, could we at least make it an attribute name that conveys the problem more obviously?

[19:52:41.0000] <zewt>
(validators whining about @alt is a good way to get people to shrug and stick an empty alt on every image just to shut it up)

[19:53:08.0000] <Hixie>
that's why the spec says conformance checkers shouldn't whine about missing alt="" in a number of cases

[19:53:44.0000] <Hixie>
hober: e.g. call it alt-attribute-invalidly-omitted-due-to-insufficient-information-at-document-creation-time="" or some such

[19:55:34.0000] <zewt>
i don't know what the criteria are, but i know it's nagged me and i've shrugged and did the quick shut-up-the-validator-so-it-doesn't-drown-out-real-problems game

[19:55:50.0000] <Hixie>
uh, missing alt is a real problem

[19:56:57.0000] <zewt>
not with anything I'm doing

[19:58:01.0000] <Hixie>
well if you're just doing private stuff, just stick alt=bogus everywhere, sure

[19:58:11.0000] <zewt>
hardly private

[19:58:14.0000] <Hixie>
or just stick a meta=generator line and be done with it

[19:58:21.0000] <Hixie>
if it's not private then how is it not a real problem?L

[19:58:30.0000] <zewt>
what problem are you assuming affects what I'm doing?

[19:59:36.0000] <Hixie>
i'm assuming you either have presentational images that you're not marking as such with alt="", and thus are peppering the output for non-image-enabled-graphical-browser users with "hey there's an important image here" notifications, or

[19:59:59.0000] <Hixie>
that you are giving content-ful images that you aren't giving alt="..." text for and are thus making such users be unable to get the full content of the page

[20:00:02.0000] <zewt>
non-image-enabled-graphical-browsers are not an important category of users to most web developers

[20:00:25.0000] <Hixie>
ah, the elitist school of web design, i see

[20:00:36.0000] <zewt>
they may be important to you, but that doesn't magically make that trivially small set of users important to people spending money to have content developed

[20:01:03.0000] <zewt>
ah, the "developer time is free and everything I think is important is important to everyone" school of web design, I see

[20:02:25.0000] <zewt>
everything is a balance of priorities, and it's not "elitist" for people to have different priorities than you

[20:03:04.0000] <Hixie>
do you also have gender fields that only have "male" and "female" options, text that can't be zoomed, diagrams that use just red and green, name fields that require a first and last name, and no js-disabled fallback, by any chance?

[20:03:40.0000] <zewt>
i sure don't spend time developing for people who turn JS off

[20:03:59.0000] <zewt>
(the development time it takes to support that is far too severe for the userbase)

[20:04:24.0000] <zewt>
i don't think there's any parallel between "deliberately turns off javascript" and colorblindness, however

[20:04:37.0000] <Hixie>
well, i hope you work for companies my employers compete against, so i can pick up all the customers you leave behind :-)

[20:04:52.0000] <zewt>
sure, you can have both of them :)

[20:05:29.0000] <Hixie>
6 billion * (3% + 1% + 1% + 1% + 1% + ...) ends up being plenty of people

[20:07:20.0000] <zewt>
i'm sympathetic to spending effort supporting people with issues they're born with (colorblindness), but less so to people who expect people to jump through hoops because of something they've done willfully (turn off images, JS, CSS)

[20:10:52.0000] <zewt>
(which is why I do use @alt if it makes sense, for screen readers; but blind people can't use our primary products--iOS games--anyway, so supporting that for most of our webpages is moot; priorities again)

[23:41:53.0000] <annevk>
MikeSmith: submitted affiliation change request

[23:42:05.0000] <MikeSmith>
thanks

[23:42:10.0000] <MikeSmith>
I will ping plh about that

[23:42:33.0000] <MikeSmith>
not sure how quickly he will get around to processing it, because he's at IETF in Vancouver

[23:42:51.0000] <MikeSmith>
and funny thing, he has been sending me some questions by e-mail now and then

[23:42:57.0000] <MikeSmith>
about various things

[23:43:20.0000] <MikeSmith>
and the funny part of it is, I can tell from the subject of the e-mails who he has been talking to at IETF

[23:43:25.0000] <MikeSmith>
without him needing to mention the name

[23:43:51.0000] <MikeSmith>
e.g., one of his questions was about the MIME sniffing draft at IETF

[23:44:23.0000] <annevk>
heh

[23:44:41.0000] <MikeSmith>
which by the way I think that's another draft we should just (re)take ownership on at this point

[23:45:06.0000] <MikeSmith>
I think it's a lot further along than the URL draft

[23:45:54.0000] <MikeSmith>
if we make it deliverable of a W3C WG I don't know which group it should go to

[23:46:00.0000] <MikeSmith>
but we could deal with that later

[23:46:26.0000] <MikeSmith>
or we just fold it back into the HTML spec where it came from

[00:00:57.0000] <Hixie>
MikeSmith: i think adam was planning on just doing that one through whatwg, i really need to get my act together in terms of making a page to put those

[00:01:10.0000] <MikeSmith>
ok

[00:01:30.0000] <MikeSmith>
I know Adam has zero plans to continue it at IETF

[00:03:25.0000] <Hixie>
right

[00:14:32.0000] <annevk>
there is http://mimesniff.spec.whatwg.org

[00:14:47.0000] <Hixie>
yeah

[00:14:57.0000] <Hixie>
it's not properly tied into everything

[00:15:16.0000] <annevk>
our spec organization is a bit of a mess still

[00:15:55.0000] <Hixie>
so earlier i suggested alt-attribute-invalidly-omitted-due-to-insufficient-information-at-document-creation-time="" as the attribute name for relaxed=""

[00:15:59.0000] <Hixie>
obviously that's a non-starter

[00:16:27.0000] <Hixie>
but how about no-alt-available-at-publication-time="" ?

[00:17:11.0000] <MikeSmith>
I could live with that

[00:17:51.0000] <Hixie>
or user-provided-image-without-alt=""

[00:18:14.0000] <MikeSmith>
I agree it's good to make it a more obviously discouraging attribute name

[00:18:46.0000] <MikeSmith>
the "user-provided" part seems kind of ambiguous (which user?)

[00:18:48.0000] <Hixie>
image-contents-unknown="" ?

[00:19:03.0000] <MikeSmith>
generator-provided-image-without-alt

[00:19:40.0000] <Hixie>
generator-provided-image-without-alt="" isn't bad

[00:20:23.0000] <Hixie>
or generator-provided-image-with-missing-alt="", to underscore that the alt is missing, not just omitted

[00:20:33.0000] <MikeSmith>
yes

[00:20:59.0000] <Hixie>
maybe generator-unable-to-provide-alt=""

[00:21:13.0000] <MikeSmith>
perhaps

[00:21:29.0000] <annevk>
back later

[00:21:36.0000] <MikeSmith>
generator-inserted-image-without-providing-alt=""

[00:21:41.0000] <Hixie>
or longer, generator-unable-to-provide-required-alt=""

[00:21:55.0000] <MikeSmith>
yeah

[00:22:01.0000] <Hixie>
i like "unable" because it implies that that's a bad thing, not a choice

[00:22:30.0000] <MikeSmith>
yeah

[00:22:31.0000] <Hixie>
of course half the authors don't speak english with enough fluency to get that, and the other half don't care, but still

[00:22:48.0000] <MikeSmith>
I don't know if that's true, but point taken

[00:23:20.0000] <MikeSmith>
will be interesting to hear hsivonen current thoughts on this

[00:23:26.0000] <Hixie>
i think i like generator-unable-to-provide-required-alt=""

[00:24:17.0000] <Hixie>
the "generator" part is good as it scopes who can say it, the "unable" and "required" parts underscore that it's bad, and the length makes it stick out so it's less likely to be cargo-culted

[00:25:15.0000] <MikeSmith>
yeah, nobody's going to want to type that manually and it's certainly going to draw their attention in the copy-paste case

[00:27:03.0000] <Hixie>
yeah, discouraging manual typing, also a good point

[00:30:08.0000] <MikeSmith>
I think I'll add experimental support for this in my validator workspace and push it to http://qa-dev.w3.org:8888/ once I've done that

[00:31:23.0000] <MikeSmith>
including adding a "Report errors for img elements with an generator-unable-to-provide-required-alt attribute." option in the UI, after the current "Show Image Report" option

[00:31:34.0000] <MikeSmith>
with it unchecked by default

[00:36:16.0000] <Hixie>
btw note that Flickr isn't a use case for this

[00:36:40.0000] <Hixie>
Flickr is handled by one of the other escape clauses (using <figure> or title="" to give the image caption)

[00:38:32.0000] <MikeSmith>
OK

[00:38:33.0000] <Hixie>
the case we're talking about here is more for things like word-to-html

[00:38:41.0000] <MikeSmith>
ah yeah

[00:56:44.0000] <Hixie>
MikeSmith: i posted about it to whatwg

[00:57:04.0000] <MikeSmith>
/me takes a look

[01:54:52.0000] <Stevef_>
hixie: why is word to HTML a use case? alt can be specified in word

[02:00:16.0000] <Stevef_>
hixie: notes on effects of conversion from several formats - Accessible Documents in HTML, Word, and PDF http://terrillthompson.com/blog/25

[02:01:58.0000] <annevk>
MikeSmith: btw, should we publish Notifications as Last Call?

[02:04:00.0000] <jgraham>
Hmm, so I am confused about base URIs + pushState. If I have <base href="base/"><a href="foobar"></a> and I pushState the URL of the link, what should the a) document location, b) document base URL and c) resolved link URL be after the pushState?

[02:04:06.0000] <MikeSmith>
Stevef_: for the case where the alt text is not specified in the source Word doc

[02:04:25.0000] <MikeSmith>
we don't validate the source Word doc

[02:04:54.0000] <Stevef_>
mikesmith: right

[02:07:09.0000] <jgraham>
TC: http://hoppipolla.co.uk/tests/pushState/001.html

[02:09:00.0000] <Stevef_>
mikesmith: on the generalization of a novalidate attribute, i can think of many situations where an author does not have control over parts of the code that are used in a page, example any 3rd party widget/ any mash up, it would be useful to be able to isolate those parts DOM tree and mark them as novailate, so errors in parts that the author can fix are not lost in the crowd

[02:09:48.0000] <MikeSmith>
Stevef_: agreed there are situations like that but I think we should deal with those on an element-by-element basis

[02:10:25.0000] <MikeSmith>
trying to create a general solution for what are in reality a variety of different problems is often (or usually) not the best idea

[02:10:50.0000] <MikeSmith>
relaxed="" is too general of a name

[02:10:56.0000] <Stevef_>
mikesmith: ok

[02:11:04.0000] <jgraham>
In particular I don't quite follow why the document base URI doesn't change (in Wecko/GeKit) when you pushState

[02:11:20.0000] <MikeSmith>
the right solution for img is something more specific and obvious like generator-unable-to-provide-required-alt

[02:17:34.0000] <Stevef_>
that could also be used as an identifier for AT to use heuristics or identify the presence of an  image without announcing garbage, i could live with that

[02:20:45.0000] <jgraham>
annevk, hsivonen: any hints for me about base URIs?

[02:23:07.0000] <Stevef_>
mikesmith: in the word to HTML case any error would fall into the bucket of machine generated can't fix

[02:23:56.0000] <Stevef_>
mikesmith: so why provide a method to ignore alt errors only?

[02:27:00.0000] <MikeSmith>
Stevef_: because that is the only one we have an open issue for

[02:27:35.0000] <MikeSmith>
my immediate goal is to try to get agreement on a solution for that one open issue, and get it resolved so we can move on to other issues

[02:27:39.0000] <annevk>
jgraham: dunno, what does the spec say?

[02:27:45.0000] <AryehGregor>
A novalidate attribute?  Like, <html novalidate> so that your page passes validation no matter what?

[02:28:14.0000] <annevk>
novalidate is taken by forms

[02:28:18.0000] <AryehGregor>
Oh, true.

[02:28:22.0000] <MikeSmith>
Stevef_, AryehGregor: I do not want to transform the need to resolve issue 206 into a general one-size-fits-all solution

[02:28:26.0000] <jgraham>
annevk: Well afaict the pushState should set the document's current address

[02:28:31.0000] <AryehGregor>
Regardless of name, it would make more sense for validators to still validate such portions of the page, just indicate the errors separately.

[02:28:50.0000] <annevk>
jgraham: okay, so then the base URL stays the same

[02:29:18.0000] <MikeSmith>
AryehGregor: that does not solve the problem of needing to make it obvious that an image is broken due to lack of alt text

[02:29:23.0000] <annevk>
jgraham: and presumably pushState resolves its argument against the base URL for the Document the script is associated with

[02:29:25.0000] <jgraham>
annevk: But "document base URL" should resolve the <base> element against the current address?

[02:29:46.0000] <annevk>
jgraham: there's no reason for document base URL to update itself

[02:30:06.0000] <AryehGregor>
MikeSmith, we don't want to introduce permanent new markup features without making sure they're designed to meet solid use-cases at the appropriate level of generality.  A quick fix to resolve an issue makes sense for non-normative requirements, but not for introducing new attributes.

[02:30:12.0000] <jgraham>
annevk: Where do it say that the base URL is static?

[02:30:17.0000] <annevk>
jgraham: it's established once, not again and again

[02:30:22.0000] <MikeSmith>
AryehGregor, Stevef_: something that is not suggested in the CP but that I think should be added is, the name of the attribute should be a big red flag that indicates the img should have alt text but is missing it

[02:30:39.0000] <annevk>
jgraham: it's not exactly static either

[02:30:41.0000] <AryehGregor>
Basically, if the author can't provide alt text for an image because they didn't provide it, it's not different from embedding any invalid content, as Stevef_ points out.  The validator should still raise an error in such a case.

[02:30:47.0000] <MikeSmith>
AryehGregor: I don't think this is a quick fix at all

[02:30:49.0000] <jgraham>
The "resolve a URL" algorithm makes it sound like it is resolved every time

[02:31:22.0000] <jgraham>
annevk: Where is this defined?

[02:31:47.0000] <annevk>
jgraham: I guess that is kind of buggy

[02:31:51.0000] <MikeSmith>
AryehGregor: i don't want to take a specific problem that we know we have for one element, and transform it into a general solution for hypothetical problems we might have with other elements

[02:32:00.0000] <annevk>
jgraham: it should only be updated if <base> mutates I think

[02:32:27.0000] <MikeSmith>
if we have similar problems with other elements, then we can introduce specific attributes for those two

[02:32:29.0000] <annevk>
jgraham: when defining document base URL I don't think Hixie considered pushState

[02:32:40.0000] <AryehGregor>
annevk, BTW, last I checked, Wikipedia still uses binary collation for (almost?) all its text columns in MySQL, because Unicode support in MySQL stinks.  E.g., indexed values have a maximum length in bytes, commonly 1000 bytes in my experience.  varchar(255) with four-byte UTF-8 could be a maximum of 1020 bytes, so MySQL will refuse to let you fully index such a column because it can't guarantee that it will always fit (even though it would h

[02:32:40.0000] <AryehGregor>
ave to be practically all non-BMP chars to go over the limit).

[02:32:48.0000] <MikeSmith>
right now, there are not a huge set of other similar problems that leap to me for me

[02:32:51.0000] <jgraham>
annevk: Sigh. OK

[02:33:16.0000] <AryehGregor>
MikeSmith, it's not hypothetical at all.  It's very common that sites embed user-submitted HTML of all kinds.  E.g., the markup of the MediaWiki interface is largely valid, but user-submitted content is all kinds of invalid.

[02:33:26.0000] <jgraham>
It is hard to get this stuff right when the spec is wrong (even if the spec is only wrong because implementations fail to follow it)

[02:33:41.0000] <AryehGregor>
(markup that's invalid in XHTML1 is generally prohibited, but there's lots of stuff that's valid XHTML1 but invalid HTML5)

[02:33:42.0000] <jgraham>
And even harder when Hixie is in a silly timezone

[02:34:17.0000] <annevk>
jgraham: well hey I helped you out ;)

[02:34:31.0000] <jgraham>
Yes, thanks :)

[02:34:44.0000] <AryehGregor>
MikeSmith, likewise blog software, forum software, etc. accepts user-submitted rich markup that might be invalid for whatever reason.  In these cases, it should generally be *possible* to automatically make it valid by substituting style="" or whatever.

[02:35:10.0000] <AryehGregor>
(although it's a real pain in the neck for some things, like cellpadding; and impossible in general in a few cases, like <center>, due to CSS limitations)

[02:35:40.0000] <MikeSmith>
I understand that the general problem is not hypothetical

[02:36:18.0000] <Stevef_>
MikeSmith: i suggest that the resolution of the particluar issue may reside in a more general approach that covers other valid use cases

[02:36:21.0000] <MikeSmith>
I just can't think of many acute cases that are like the img@alt case that we have disagreement about how to deal with

[02:36:55.0000] <MikeSmith>
Stevef_: I am not ruling that out

[02:37:18.0000] <MikeSmith>
but I am also very wary of solutions that try to do that

[02:38:12.0000] <MikeSmith>
and please think this through

[02:38:39.0000] <MikeSmith>
say we make a global attribute called "novalidate" or "invalid" or whatever to flag stuff that the author knows is not valid

[02:39:24.0000] <MikeSmith>
what prevents authors from abusing the hell out of that and just putting it anywhere they have broken markup that they don't want to fix or don't have the time to fix?

[02:40:04.0000] <MikeSmith>
the general approach gives them an easy out

[02:43:09.0000] <Stevef_>
mikesmith: ok so if the alt attribute was a long name such as generator-unable-to-provide-required-alt="" why would they use it over alt="" since both silence the validator?

[02:45:47.0000] <MikeSmith>
they wouldn't

[02:45:57.0000] <MikeSmith>
people wouldn't

[02:46:13.0000] <MikeSmith>
nobody is expected to manually put that into their markup

[02:46:25.0000] <MikeSmith>
it's solely intended for generators to add to img elements

[02:46:30.0000] <MikeSmith>
machines, not people

[02:47:51.0000] <Stevef_>
mikesmith: ok

[02:48:43.0000] <Stevef_>
mikesmith: so there should be conformance requirments about who can use it right?

[02:49:01.0000] <Stevef_>
mikesmith: under what circumstances

[02:53:49.0000] <Stevef_>
only for use in automated markup generators an document format conversion tools. Not for use in WYSIWYG editors etc

[02:57:39.0000] <MikeSmith>
Stevef_: yeah, that would be what I would restrict it to

[02:57:59.0000] <MikeSmith>
tools that do not require human intervention in order to generate the markup they generate

[02:58:21.0000] <MikeSmith>
they may be parts for some bigger system, like what the CP describes

[02:59:00.0000] <MikeSmith>
the author is working in a WYSIWG editor to create the part of the page/application/content they are directly responsible for

[02:59:44.0000] <MikeSmith>
then the system combines that manually authored content with machine-generated content to produce a page

[03:00:00.0000] <MikeSmith>
the author then wants to validate that completed page

[03:00:02.0000] <Stevef_>
then it sounds like a reasonable aproach, but it should be advised that its use must not be used as a reason not to provide downstream authors with a method to add alt text

[03:00:11.0000] <MikeSmith>
sure

[03:17:17.0000] <Stevef_>
mikesmith: so the current wording around the meta exception would need to be tightened up,  "identifies one of the software packages used to generate the document. This value must not be used on hand-authored pages." as presumably hand authored pages don't make the cut and 'software packages' could mean anything

[03:18:32.0000] <MikeSmith>
Stevef_: I think if we did generator-unable-to-provide-required-alt it would mean removing some of that language completely

[03:20:51.0000] <Stevef_>
sure

[03:40:56.0000] <MikeSmith>
It's depressing to hear dude already saying "I’ll be objecting to this proposed relaxed attribute" at this point in the discussion about Ted's CP

[04:25:29.0000] <hsivonen>
MikeSmith: It's also depressing but it's possible to correctly guess who the dude is.

[04:25:50.0000] <MikeSmith>
heh

[04:30:11.0000] <annevk>
public-html is fun

[04:30:30.0000] <annevk>
"I respect the fact that Ted worked on this in good faith, and under the desire to make things better." hard to not read that as "fuck you"

[04:35:50.0000] <annevk>
that we're still discussing <img alt> in 2012 is kinda weird too

[04:36:29.0000] <hsivonen>
annevk: because the chairing hasn't been like this http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0212.html

[04:37:08.0000] <annevk>
yeah, although I didn't quite like that he used "consensus" there

[04:39:33.0000] <annevk>
with <img alt> some kind of end user study would be interesting

[04:39:51.0000] <annevk>
the people I know that are blind never have much of a problem with me sharing an image every now and then

[04:42:40.0000] <annevk>
like if K shares a photo of the beach on Facebook, does a blind person feel left out because it lacks <img alt>?

[04:42:53.0000] <annevk>
and even if some do, is it reasonable to expect that situation to change?

[04:44:29.0000] <annevk>
it makes sense to have alt for <a href=/about><img src=/about.png alt="About us"></a> of course, but it's a lot harder with discussion platforms

[04:47:20.0000] <annevk>
http://www.spiegel.de/international/zeitgeist/no-copyright-law-the-real-reason-for-germany-s-industrial-expansion-a-710976.html is pretty interesting

[04:52:02.0000] <odinho>
annevk: Cool.

[04:56:42.0000] <AryehGregor>
Who's a good reviewer to ask for <https://bugzilla.mozilla.org/show_bug.cgi?id=751554>?  It will presumably be in MFBT.

[04:57:51.0000] <jgraham>
One in #developers? :p

[04:58:21.0000] <AryehGregor>
Sigh!

[04:58:26.0000] <AryehGregor>
I do that far too often.

[04:58:36.0000] <AryehGregor>
I need a better way to visually distinguish these two windows.

[04:58:38.0000] <AryehGregor>
/me grumbles

[04:58:51.0000] <AryehGregor>
(thanks for the correction)

[04:59:46.0000] <jgraham>
/me has no idea what MFBT is but has seen a bunch of blog posts from Jeff Walden that seem to be at a similar infrastructure level fwiw

[05:00:36.0000] <jgraham>
(I think)

[05:00:51.0000] <jgraham>
(althought it might have been someone else, and it might be totally unrelated)

[05:01:14.0000] <jgraham>
(so that was really a totally unhelpful comment)

[05:01:50.0000] <AryehGregor>
Yeah, I know he's a possible review candidate, just not sure if he's the best one -- I think I saw that he was away or something.

[05:02:15.0000] <jgraham>
I believe he is currently on a bicycle in the desert somewhere

[05:02:34.0000] <jgraham>
(or whatever they call the bit of the USA that isn't on the coasts)

[05:03:13.0000] <jgraham>
Reading planet.mozilla is great

[05:03:25.0000] <odinho>
jgraham: you corporate spy

[05:04:25.0000] <jgraham>
odinho: Not sure what I am spying on unless his bike trip is actually a secret mission :p

[05:05:04.0000] <odinho>
jgraham: Who's to say it isn't? :P

[05:11:04.0000] <AryehGregor>
jgraham, MFBT is Mozilla Framework Based on Templates, basically an attempt to write a library of easily-reusable generic macros/templates/etc.

[05:11:13.0000] <AryehGregor>
From scratch, with no dependencies on other Gecko stuff.

[05:12:03.0000] <AryehGregor>
I'm trying to get support for C++11's "enum class" feature, so I need to write a wrapper for old compiler versions.

[05:12:14.0000] <AryehGregor>
And that seems like the trendy place to put stuff like that these days.

[05:12:17.0000] <jgraham>
Ah. I think I remember seeing the acronym before because it is a rearragement of MTBF

[05:12:23.0000] <AryehGregor>
Yes, it's very confusing.

[05:12:43.0000] <AryehGregor>
Especially since I always misremember it as "Mozilla Template-Based Framework", which of course does abbreviate to MTBF.

[05:12:43.0000] <jgraham>
I would totally have called it Mozilla Template Based Framework

[05:12:50.0000] <jgraham>
heh

[05:13:01.0000] <AryehGregor>
Maybe they did originally, and it proved too confusing . . .

[05:13:47.0000] <jgraham>
Maybe they didn't want to set themselves up for the obvious jokes when it fails :)

[05:21:39.0000] <hsivonen>
AryehGregor: I believe it's easier to remember if you think of it as an abbreviation for Mozilla Friday Beer Time.

[05:25:16.0000] <AryehGregor>
jgraham, also, as someone who grew up in Manhattan, I agree that the non-coastal parts of the US qualify as desert.

[05:25:41.0000] <AryehGregor>
The outer boroughs of New York City are suburbs, and anything outside the city limits is countryside.

[05:26:02.0000] <AryehGregor>
(My wife grew up in Queens, and does not agree that it is the suburbs, but she's biased)

[05:56:37.0000] <annevk>
and you're not biased? lol

[06:37:20.0000] <sedovsek>
Hey.

[06:37:23.0000] <sedovsek>
Shorthand for 'background' property does not work if it includes background-size?

[08:50:16.0000] <garciawebdev>
how is your code?

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

[09:10:22.0000] <Ms2ger>
Good day

[09:42:51.0000] <Hixie>
jgraham: here now if you still have a question

[09:43:33.0000] <Hixie>
jgraham: was the problem just that the spec doesn't cache the base url when it's specified as a relative url?

[10:04:18.0000] <Hixie>
hsivonen: alt="" indicates that the image is decorative and can (and should) be skipped when it comes to users whose primary experience of the page doesn't include images.

[10:05:03.0000] <Hixie>
hsivonen: a missing alt="" attribute indicates that the image doesn't have an alt attribute, which is either a mistake, or means that the image is key content but that the page generator couldn't provide alternative text

[10:05:20.0000] <Hixie>
hsivonen: treating them as equivalent is thus not reasonable

[10:45:20.0000] <Hixie>
it strikes me that maybe there shouldn't be a limit on how many, say, autocomplete=cc-csc fields a form has

[10:45:32.0000] <Hixie>
they'll all have to be autofilled with the same value, but that's ok

[10:45:41.0000] <Hixie>
authors already ask for e.g. the e-mail to be given twice to confirm it

[10:46:33.0000] <Hixie>
i don't really see why someone would ask for both a tel-local and a tel-local-prefix and tel-local-suffix, but maybe they have a radio button that controls what the input looks like or something...

[11:54:34.0000] <jgraham>
Hixie: The problem was that the spec doesn't cache the base URL at all

[11:54:52.0000] <jgraham>
It recomputes it every time that something is resolved

[11:55:28.0000] <jgraham>
Which doesn't seem to match browsers, at least to the extent that pushState doesn't seem to affect the base URI

[11:58:33.0000] <Ms2ger>
Is http://wiki.whatwg.org/wiki/StringEncoding something we should implement?

[12:00:14.0000] <jgraham>
Ms2ger: I thought people seemed quite happy about that API at least

[12:00:25.0000] <Hixie>
jgraham: k, didn't test that, good to know. can you file a bug / send e-mail?

[12:00:57.0000] <Ms2ger>
Won't complain about it, then

[12:01:06.0000] <Hixie>
it makes sense that base urls wouldn't be reresolved, after all, nothing else does :-)

[12:01:13.0000] <Hixie>
s/does/is/

[12:02:28.0000] <jgraham>
Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18459

[12:02:34.0000] <Hixie>
awesome, thanks

[12:05:08.0000] <Hixie>
hsivonen, hober: your input on http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0004.html would be helpful

[12:05:29.0000] <Hixie>
hsivonen, hober: since MikeSmith is implementing, i intend to get to this as soon as i'm done with autocomplete=""

[12:05:42.0000] <Hixie>
which may be later tday

[12:25:58.0000] <Hixie>
Stevef_: any chance i can convince you to use regular quoting style on the whatwg list? it's great that you're posting, and i'm really glad to see productive conversations going on, but your quoting style is going to make replying to all the e-mails somewhat complicated for me

[12:26:25.0000] <__doc__>
I'm interested to get drawing tablets to work with browsers and have some standard for that. Any idea how I can get that ball rolling?

[12:27:14.0000] <Hixie>
__doc__: best first step is to convince a browser vendor to add experimental support for such a feature, so we get implementation experience

[12:27:30.0000] <__doc__>
/me nods

[12:27:30.0000] <Hixie>
see http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

[12:27:40.0000] <Hixie>
lunch, bbl

[13:12:24.0000] <Yuhong>
Win8 just RTMed and ships with IE10: http://blogs.msdn.com/b/b8/archive/2012/08/01/releasing-windows-8-august-1-2012.aspx

[13:12:54.0000] <Yuhong>
And on CSS style modularization of HTML, remember the "HTML5" buzzword will not disappear overnight.

[13:33:08.0000] <__doc__>
and with wart shutting out competing browsers, a lot of emerging standards will yet again be held up by microsoft

[13:34:53.0000] <zewt>
does adams actually represent a real vendor?  now he's declaring an objection in advance, without even pretending that he's interested in discussion, and I'm inclined to ignore him, heh

[13:36:26.0000] <Ms2ger>
Don't think so

[13:38:19.0000] <zewt>
he's saying he'll "object" and that we should "deal with it now", heh

[13:40:34.0000] <Ms2ger>
I read it

[15:34:37.0000] <zewt>
well, i'm inclined to ignore him, heh

[15:35:28.0000] <zewt>
though if somebody knows who he is it would be nice (if perhaps not useful) to know who it is that's behaving like that, heh

[15:41:54.0000] <jamesr_>
glenn adams?

[15:42:59.0000] <zewt>
yeah

[15:43:22.0000] <jamesr_>
my understanding is that he is (or is employeed by) a w3c member, so if he says "I OBJECT!" he has equal weight to any other member within the w3c

[15:43:52.0000] <jamesr_>
imo he's also more than a little bit of a nut at times, to the point where if somebody talks about something "glenn" did i have to ask "do you mean zewt or the crazy glenn?"

[15:43:55.0000] <zewt>
well, if he's speaking on behalf of someone, i'd just be interested in knowing, since he's (in my opinion) behaving very poorly

[15:44:46.0000] <zewt>
(now he appears to be preemptively objecting to anything that doesn't somehow magically combine blob-style access and WebSockets)

[15:44:56.0000] <jamesr_>
i don't know what his organizational relationship is with the w3c. it's not with any browser vendor

[15:45:07.0000] <gsnedders>
Works for Cox, though quite what Cox have to do with HTML is interestingly.

[15:45:18.0000] <gsnedders>
*interesting

[15:45:58.0000] <jamesr_>
http://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html lists him as working for Cox, and http://www.w3.org/Consortium/Member/List says Cox is a W3C member

[15:46:41.0000] <Hixie>
jamesr_: there's a difference in weight between members

[15:46:54.0000] <Hixie>
jamesr_: those who implement have more practical weight than those who don't :-)

[15:46:57.0000] <jamesr_>
he's also editor on a couple css specs (and i don't think he's gone crazy there)

[15:46:58.0000] <zewt>
all I can do is hope that in reality if the real players (eg. real-world browser vendors) like it, an objection from someone like that won't actually have much effect

[15:47:27.0000] <smus>
someone mentioned that <img srcset> works in Safari on iOS 6. I can't get it to work using http://smus.com/m/srcset/ (on any browser)

[15:47:29.0000] <zewt>
(not that i wouldn't discuss it if he was making an interesting case, but all he's doing is derailing the hell out of the thread)

[15:47:45.0000] <jamesr_>
i think he's a known entity to most browser devs, but it depends on how much they care about w3c process and whatnot. he's definitely gone nuts before in a few places and i think been mostly ignored

[15:48:50.0000] <jamesr_>
Hixie, he can be a pain in the butt still, especially for editors/specs who are stuck with more w3c

[15:49:57.0000] <Hixie>
i don't see how he can be a pain unless people voluntarily opt-in to the bureaucratic process

[15:50:12.0000] <zewt>
Hixie: that's why i'm carefully opting-out and ignoring his threat :)

[15:50:13.0000] <Hixie>
and people who opt-in to that process are doing so of their own free will, so they deserve what they get

[15:50:20.0000] <Hixie>
zewt: indeed

[15:50:31.0000] <zewt>
i'll stick to the technical discussion and leave it to the politicians (so to speak) to deal with any w3c process crap later

[15:50:36.0000] <Hixie>
ok anyone see anything wrong in the new autocomplete section?

[15:51:31.0000] <paul_irish>
link?

[15:51:34.0000] <zewt>
(doing a read through)

[15:52:14.0000] <Hixie>
paul_irish: http://www.whatwg.org/specs/web-apps/current-work/#autofilling-form-controls:-the-autocomplete-attribute

[15:52:21.0000] <Hixie>
(sorry, not in multipage version yet)

[15:52:23.0000] <paul_irish>
thx

[15:53:45.0000] <zewt>
are locality and region intentionally vague for different regions?

[15:54:57.0000] <zewt>
i remember having to ship USPS (iirc) to Korea, and it was a 45 minute ordeal trying to split it apart into its components, since they had separate form fields for each and I didn't know what was what

[15:55:33.0000] <Hixie>
they're hte terms vCard uses

[15:55:34.0000] <zewt>
for horror's sake, that address (minus street numbers) was: Mcity tower 12346, 123 Changhang-dong, Ilsandong-gu, Koyang-si, Kyonggi-do, 410-380, Korea

[15:55:48.0000] <Hixie>
yikes

[15:55:51.0000] <zewt>
indeed

[15:55:59.0000] <Hixie>
yeah, having fields for address is pretty much bogus, but that's the way people do it, so...

[15:56:11.0000] <zewt>
apparently those suffixes are roughly analogous to city, state, province, etc

[15:56:19.0000] <Hixie>
i tried to provide generic fields where possible (name, e.g.)

[15:58:31.0000] <gavinc>
Hixie: I don't think cc-name makes a great deal of sense broken down, was there research on that? As far as I'm aware payment systems tend to simply take full name

[15:58:40.0000] <gavinc>
sorry, the cc-name breakdown

[16:04:25.0000] <Hixie>
gavinc: i added those because http://wiki.whatwg.org/wiki/Autocomplete_Types had them, but will investigate further...

[16:05:26.0000] <Hixie>
https://www.teleconference.att.com/resv/help/My_Profile/Credit_Cards/Add_a_Credit_Card.htm suggests at least some forms do have them separated

[16:06:57.0000] <gavinc>
gah, okay, I buy it now, but still gah

[16:07:07.0000] <Hixie>
oh i'm with you 100%

[16:07:20.0000] <Hixie>
the regular name fields being split out is just as ridiculous

[16:07:27.0000] <Hixie>
many people don't have more than one name

[16:07:32.0000] <gavinc>
Yeah, but I get WHY people do it

[16:07:47.0000] <gavinc>
for the cc... I mean, the payment gateways don't

[16:08:03.0000] <gavinc>
and the magstrip doesn't encode it

[16:08:25.0000] <gavinc>
so that's just really bad form design

[16:09:19.0000] <zewt>
the most awesome part is how it totally screws pasting in info

[16:09:50.0000] <gavinc>
I was thinking the most awesome part being that my wife couldn't fill in the form ;)

[16:11:14.0000] <Hixie>
plenty of people have that problem

[16:11:23.0000] <Hixie>
e.g. required phone number fields for people with no phones (e.g. me)

[16:11:37.0000] <Hixie>
sex fields that only accept "male" and "female"

[16:11:44.0000] <Hixie>
name fields that require a first and last name

[16:12:12.0000] <Hixie>
address fields for addresses like the one zewt pasted in earlier

[16:12:31.0000] <zewt>
heh

[16:12:40.0000] <zewt>
my work just had to buy a cheapo cellphone

[16:12:59.0000] <zewt>
because we need to do facebook dev, and there's no way to validate a FB account for development except a cellphone

[16:13:08.0000] <zewt>
(landlines are out, since it assumes you can receive an SMS)

[16:15:26.0000] <gavinc>
Not only that but not all cell phones work

[16:16:40.0000] <zewt>
also fun was while I was living in MA, anything sent USPS had to have the 9-digit zip code, or be delayed or lost

[16:16:51.0000] <zewt>
... and of course, lots of forms limit zip code entry to 5 digits

[16:17:19.0000] <zewt>
and (if you can believe it) some of them would accept 9 digits, then they'd only use 5

[16:17:47.0000] <zewt>
(often intentionally, eg. handwritten shipping slips, which means some idiot went "why is this guy giving me 9 digits? i'm going to save ink and only write out 5!")

[16:18:27.0000] <zewt>
humanity is stunningly innovative in finding new ways to screw up in stupid ways :)

[16:20:32.0000] <gavinc>
Mmm, but if the auto fill fields are specified as broken out for ccname aren't we going to be asking browser vendors to make UIs that some how have to divide up the name that for a CC really can't be?

[16:20:57.0000] <gavinc>
wouldn't it in fact be BETTER if auto fill didn't work on pages where the cc name is broken up?

[16:21:09.0000] <Hixie>
i'm presuming the UI would just be slurping data from other forms

[16:21:50.0000] <gavinc>
LastPass and OnePassword are likely better examples for credit card info

[16:22:03.0000] <zewt>
i'd think that cc billing name *has* to be a single form entry

[16:22:18.0000] <zewt>
since you want to enter the name exactly as it is on the card, and that can eg. include or not include a middle initial

[16:22:27.0000] <Hixie>
chrome already tries to autofill credit card info for me, and i never told it my info other than by filling in another form...

[16:23:30.0000] <zewt>
Hixie: is it expected that some of these labels would only actually be used to say "don't remember this field at all" (eg. cc-csc)?

[16:23:41.0000] <zewt>
(and probably in most sane cases cc-number too)

[16:24:23.0000] <zewt>
(in terms of what browsers would do with it, I mean)

[16:29:04.0000] <Hixie>
why would you not remember cc-csc?

[16:29:45.0000] <zewt>
isn't the whole point of those that they're never actually stored anywhere

[16:30:32.0000] <Hixie>
they're stored on my card

[16:30:44.0000] <Hixie>
why can't they be stored in my (more secure) browser?

[16:30:44.0000] <zewt>
but not in retail databases, etc

[16:30:53.0000] <Hixie>
nobody is saying to store it in retail databases, sure

[16:31:07.0000] <Hixie>
we're talking about browsers here, not retail databases

[16:31:23.0000] <zewt>
from what i understand, it's meant as an extra check that you actually have the card ... for example, so it's harder to use a cc# if you steal someone's history DB from their browser

[16:31:52.0000] <zewt>
browsers are much more vulnerable (in the typical case) than retail databases--typical users get viruses on a daily basis, and no typical user is going to password-lock their browser

[16:32:07.0000] <Hixie>
i am happy to run the risk that someone will steal my browser for the convenience of not having to type in this damn number over and over

[16:32:19.0000] <zewt>
(everyone who does "mom's computer support" knows how often those things happen, heh)

[16:32:21.0000] <Hixie>
(my laptop is a hell of a lot more secure than my wallet)

[16:32:42.0000] <zewt>
Hixie: that's fine for you; it'd be a very seriously bad idea for more typical users

[16:33:07.0000] <Hixie>
well they can have it not stored if they want

[16:33:08.0000] <zewt>
i mean, if browsers want to have an "i know what I'm doing, so store this", fine, I just don't think it'd be sane at all for most users

[16:45:32.0000] <zewt>
Hixie: minor: for postal-code, maybe use a 9-digit zip as the example instead of 5

[16:46:46.0000] <Hixie>
if you can find me tim's 9-digit code, i'll get all over that :-)

[16:47:13.0000] <zewt>
who cares what tim's is? heh

[16:47:38.0000] <zewt>
oh yeah. credit card type

[16:47:47.0000] <zewt>
(visa, mastercard)

[16:48:11.0000] <zewt>
suppose that's usually a dropdown and not a text, so maybe it doesn't need help

[16:48:16.0000] <Hixie>
that's already there

[16:48:26.0000] <Hixie>
it's the first digit of the cc-number field

[16:48:42.0000] <zewt>
sure, but lots of sites ask for it separately anyway

[16:49:21.0000] <Hixie>
true, inexplicably

[16:49:27.0000] <Hixie>
not sure what to do about it

[16:49:39.0000] <zewt>
well, it's explainable, it's just not for a good reason :)

[16:49:39.0000] <Hixie>
the values are probably difficult to distinguish heuristically

[16:49:42.0000] <zewt>
(namely, incompetence)

[16:49:44.0000] <Hixie>
what's the reason?

[16:49:48.0000] <Hixie>
i mean, what do they do with it?

[16:49:58.0000] <zewt>
no idea, never written a payment service

[16:50:02.0000] <Hixie>
heh

[16:50:10.0000] <zewt>
(and I might not know if I had, since as you said it's redundant)

[16:50:18.0000] <gavinc>
It is possible to not be able to accept some CC types

[16:50:41.0000] <gavinc>
also to use diffrent payment gateways depending on type

[16:52:28.0000] <zewt>
are the values that difficult? there are maybe under a dozen values (at least commonly used in the US)

[16:52:49.0000] <zewt>
er, under half a dozen

[16:53:02.0000] <gavinc>
Oh, no

[16:53:05.0000] <gavinc>
Easy as heck

[16:53:14.0000] <zewt>
(asking because I'd expect it to be easy)

[16:53:47.0000] <gavinc>
BUT by having two fields (at least this was on POS) you can do a better job of checking if the entry of CC number worked correctly

[16:53:58.0000] <gavinc>
if someone says the type is this, and the number is that...

[16:54:05.0000] <Hixie>
it's literally just a number lookup: http://en.wikipedia.org/wiki/Bank_card_number

[16:54:07.0000] <zewt>
cc#'s have a validation digit anyway, right?

[16:54:20.0000] <gavinc>
I'm not claiming it's rational :P

[16:54:20.0000] <zewt>
Hixie: i'm not saying sites should do it, just that they do :)

[16:54:33.0000] <Hixie>
yeah, cc's have built-in check codes, see same wikipedia page

[16:54:34.0000] <Hixie>
:-)

[16:54:46.0000] <zewt>
(and there are a lot of values in this autocomplete feature that seem to be there based on that criteria :)

[16:54:50.0000] <gavinc>
Yeah, it's just mod 10

[16:56:27.0000] <zewt>
if the autocomplete spec seemed to be trying to omit things people shouldn't be doing, to try to discourage them from doing it, then yeah it might make sense to omit credit card type too

[16:56:47.0000] <zewt>
doesn't seem to be your goal, though...

[16:56:56.0000] <Hixie>
the problem with credit card type is that nobody's done the research to see if the values are heuristically recognisable, nothing else

[16:57:09.0000] <Hixie>
i have no objection to adding it if it is actually implementable

[16:57:50.0000] <zewt>
well, the heuristic matching would probably have to be on the text of the option, not the @value

[16:58:01.0000] <Hixie>
most pages i've seen use images

[16:58:07.0000] <Hixie>
(anecdotally)

[16:59:47.0000] <gavinc>
anecdotally, lasspass and 1Password don't store type


2012-08-02
[17:00:01.0000] <gavinc>
and only store "Name On Card"

[17:00:21.0000] <gavinc>
Oh!

[17:00:24.0000] <gavinc>
That's the other value :\

[17:00:30.0000] <gavinc>
Start Date for cc

[17:00:48.0000] <zewt>
i'd expect most things saving this stuff to be really conservative, not wanting to be liable for breaches

[17:01:10.0000] <gavinc>
and issue number :\

[17:01:14.0000] <gavinc>
for Maestro cards

[17:01:27.0000] <Hixie>
gavinc: fwiw, i'm not particularly married to the idea of keeping the name on card stuff, in fact i've been trying to contact the chrome guy who did the research for chrome to see what his opinion is on dropping it

[17:01:31.0000] <Hixie>
haven't been able to get a hold of him yet

[17:01:48.0000] <Hixie>
the separated cc name fields, i mean

[17:02:03.0000] <Hixie>
adding these other fields seems reasonable, do lastpass and 1pass do them?

[17:02:11.0000] <gavinc>
yep

[17:02:14.0000] <zewt>
also fwiw (and also anecdotal), i can't recall ever seeing a cc form with a separated name field

[17:02:26.0000] <gavinc>
zewt: Hixie found one :(

[17:02:39.0000] <Hixie>
zewt: do a google search for "first name on credit card" or some such, it shows a bunch

[17:03:10.0000] <Hixie>
the original list of fields was the result of the chrome guys doing some research into what form fields were common, fwiw

[17:03:10.0000] <zewt>
that seems like it would fail all over the place, eg. if someone's billing name is "mr. first last" and the billing is refused if they can't enter it exactly like that

[17:03:30.0000] <Hixie>
it's not like they're just made up :-)

[17:21:09.0000] <Hixie>
ok didn't quite finish autocomplete today. still have a section to add that talks about autocomplete vs inputmode vs type

[17:21:14.0000] <Hixie>
bbiab.

[21:27:58.0000] <Hixie>
hey anyone understand this lazyblob thread well enough to give me an elevator pitch on what it's for and how it might theoretically affect websockets?

[21:28:38.0000] <Hixie>
(zewt maybe?)

[21:38:23.0000] <zewt>
the initial post is basically: some way to take a URL that you might fetch with eg. xhr (including origin, cookies, etc.), package that up and postMessage it somewhere else, so that the other side can load it

[21:38:31.0000] <zewt>
i don't think it has the slightest thing to do with websockets

[21:41:22.0000] <Hixie>
ah, ok, excellent. thanks.

[21:41:52.0000] <Hixie>
(interesting idea, from a technical perspective, basically a closure for a url load? what's the use case?)

[21:42:55.0000] <zewt>
don't recall the use cases from the OP off-hand, but i could see, for example, being able to pass a large authenticated resource (say, a movie) to another page without that page having to be given authentication info

[21:43:17.0000] <zewt>
(specific use cases--why you'd want to do that--i don't have handy)

[21:43:44.0000] <Hixie>
specific use cases seem rather important to the question of "why would we bother" :-)

[21:43:57.0000] <zewt>
yep, sorry, the limits of 11:45 pm :)

[21:44:07.0000] <Hixie>
:-)

[21:44:19.0000] <Hixie>
/me asks the other glenn for use cases for this websocket stuff

[21:44:58.0000] <Hixie>
i'm happy to let this thread rathole itself when it involves specs i haven't got the time to deal with, like xhr, but when we start threatening to give me additional work i suddenly start caring about why we're having the discussion :-P

[21:48:22.0000] <zewt>
and I'm going to go to bed before I accidentally click the "webapps (1)" tab and end up being up for another half hour wasting time responding to (as I can make a guess at who the (1) is)

[21:49:00.0000] <Hixie>
heh

[21:49:05.0000] <Hixie>
me, in this case, i think :-)

[21:49:25.0000] <zewt>
less bothersome, then :)

[02:10:48.0000] <hsivonen>
What's the key difference between the two aria-describedby/hidden change proposals?

[02:35:39.0000] <__doc__>
/me has has his first days fill of w3c ML messages, is it always like this over there?

[02:40:18.0000] <jgraham>
__doc__: Depening on which list "yes" or "only when talking about a11y"

[02:42:05.0000] <hsivonen>
Someone should make it a policy to Formally Object to compromises to make sure that other threats of Formal Objections don't lead to compromises.

[02:50:06.0000] <__doc__>
hsivonen: wait, what? :)

[02:50:44.0000] <smaug____>
Ms2ger: eh, implementing session history defined in any spec? really?

[02:51:11.0000] <Ms2ger>
More likely going to be the WHATWG spec than a TR page from years back, though

[02:51:18.0000] <smaug____>
that is true

[02:51:50.0000] <smaug____>
someone from Opera was going to spec session history properly, or at least test it... I wonder what happened to that

[02:53:30.0000] <Ms2ger>
/me tries to remember how to declare a charset in XML

[02:56:18.0000] <__doc__>
Ms2ger: encoding attribute on the xml meta tag

[03:00:48.0000] <hsivonen>
so the Chairs decided to adopt http://www.w3.org/html/wg/wiki/FlowContentInObject

[03:01:01.0000] <hsivonen>
will Hixie align the WHATWG spec?

[03:22:13.0000] <AryehGregor>
hsivonen, do any validators care what the HTMLWG spec says?

[03:23:44.0000] <Ms2ger>
AryehGregor, the W3C validator, apparently

[03:23:58.0000] <AryehGregor>
It has its own?

[03:24:23.0000] <hsivonen>
AryehGregor: I'm not sure yet how much Validator.nu should care.

[03:26:36.0000] <hsivonen>
AryehGregor: The W3C deploys a validator built from the Validator.nu code base with W3C-specific settings. For example, the W3C instance provides an option to enable non-Lite RDFa 1.1 while Validator.nu does not.

[03:26:42.0000] <AryehGregor>
Ah, I see.

[03:29:19.0000] <MikeSmith>
AryehGregor: http://validator.w3.org/nu/

[03:30:20.0000] <MikeSmith>
that is currently doing about 9.4 page validations per second, if the data from Henri's stats feature are to be believed

[03:30:44.0000] <MikeSmith>
or around 800,000 pages per day

[03:30:54.0000] <MikeSmith>
if my adding skills are to be believed

[03:31:03.0000] <hsivonen>
AryehGregor: I wouldn't be too surprised if the end result was making Validator.nu follow the more permissive spec on each point where the two specs disagree.

[03:31:23.0000] <AryehGregor>
Interesting.

[03:31:45.0000] <AryehGregor>
It seems fairly pointless to have two different sets of authoring conformance requirements.

[03:31:53.0000] <hsivonen>
AryehGregor: indeed

[03:31:55.0000] <AryehGregor>
But then, I don't care much about authoring conformance requirements to start with.

[03:33:24.0000] <MikeSmith>
hsivonen: btw, I have an little idea I've been wanting to ask you about that I hope you won't think is too radical to be worth discussing.

[03:33:45.0000] <MikeSmith>
the idea is, don't have the validator give any kind of binary pass/fail indicator at all

[03:33:53.0000] <MikeSmith>
in the validation results

[03:34:15.0000] <MikeSmith>
specifically, don't have it output either the "The document validates according to the specified schema(s) and to additional constraints checked by the validator." or the "There were errors." text

[03:34:53.0000] <hsivonen>
MikeSmith: That would indeed be radical. :-)

[03:35:02.0000] <MikeSmith>
in the case of the "There were errors." text, that's already clear because the errors are displayed (unless/until we add the filtering feature)

[03:35:31.0000] <MikeSmith>
hsivonen: I suggest it because I think way to many people get hung up on the idea of passing or failing validation

[03:35:37.0000] <MikeSmith>
which really is not the point

[03:35:41.0000] <MikeSmith>
it's a distraction

[03:36:10.0000] <MikeSmith>
and also because we are lying if we claim we can guarantee a document actually conforms to the spec

[03:36:16.0000] <hsivonen>
I guess this would be taking the "no badge" approach to the next level.

[03:36:23.0000] <MikeSmith>
yeah

[03:36:55.0000] <MikeSmith>
for one thing, we know that right now, there are a significant number of conformance constraints in the spec that we are not checking

[03:37:08.0000] <MikeSmith>
that will of course change over time as we implement those checks

[03:37:59.0000] <MikeSmith>
also there are some constraints that are not practically machine-checkable or even machine-checkable at all

[03:38:11.0000] <hsivonen>
The zero-message case would need some indication that the validator actually ran, though.

[03:38:17.0000] <MikeSmith>
of course

[03:38:19.0000] <MikeSmith>
yeah

[03:38:55.0000] <MikeSmith>
but that would be the same generic message for the no-errors case and the has-errors cases

[03:38:58.0000] <MikeSmith>
*case

[03:39:50.0000] <hsivonen>
maybe it should be the message that says which conformance definition ("HTML + SVG + MathML") was used

[03:40:01.0000] <MikeSmith>
ah yeah

[03:40:02.0000] <MikeSmith>
true

[03:40:09.0000] <MikeSmith>
it should say that as a minimum

[03:40:47.0000] <MikeSmith>
anyway, I just wanted to put a bug in your ear about it now

[03:40:55.0000] <hsivonen>
ok

[03:41:07.0000] <MikeSmith>
we can talk more about it later if you think it's actually worth exploring

[03:41:13.0000] <MikeSmith>
right now I got to take a break for a bit

[03:46:36.0000] <AryehGregor>
It should say something like "No errors found."

[03:48:27.0000] <AryehGregor>
Of course, there's always the question of why we want validators anyway.  To tell authors about possible errors they might not know about?  To pressure authors not to do things we don't like, even if it might not be worth it to them to change?  To give third parties information about how much the author cares about standards?

[03:48:46.0000] <AryehGregor>
I have serious doubts about the usefulness of validators for any purpose other than as a lint-like tool to tell authors about possible mistkaes.

[03:48:47.0000] <AryehGregor>
mistakes.

[03:49:14.0000] <AryehGregor>
The major practical implication is that if that's all we care about, authors should be given a way to suppress arbitrary errors in case they don't care about them, as lint tools tend to permit (e.g., compiler warning flags).

[03:50:05.0000] <AryehGregor>
Also, if that's the primary use, there's no real reason to have anything specified formally.

[03:50:16.0000] <AryehGregor>
It may as well just be whatever the tool author thinks is useful.

[03:55:09.0000] <karlcow>
A validator tool in a publishing process (before final publication) is a bit like a compass when sailing it helps keep the route. That's the main benefit.

[03:56:02.0000] <AryehGregor>
In that case, it should be possible for authors to disable warnings they don't care about, perhaps with special markup in the page.

[03:58:35.0000] <jgraham>
I thought validation was a concept introduced by Microsoft to tie up people developing web tech in pointless arguments, thus preventing them working on useful features and allowing proprietary platforms to triumph

[05:21:11.0000] <MikeSmith>
AryehGregor: "lint-like tool to tell authors about possible mistakes" is much closer to what validator.nu is in practice

[05:21:19.0000] <MikeSmith>
than to traditional validator

[05:22:11.0000] <MikeSmith>
and the rules in the spec can be seen as best-practice linting rules

[05:22:39.0000] <MikeSmith>
with the idea that it's useful to have some standard best-practice linting rules for validators to converge on

[05:23:35.0000] <MikeSmith>
AryehGregor: as far as "authors should be given a way to suppress arbitrary errors in case they don't care about them", you should take a look at http://validator.keegan.st/ if you've not already

[05:24:05.0000] <MikeSmith>
that allows you to show/hide/filter messages as you'd like

[05:24:14.0000] <MikeSmith>
and the choices are persistent

[05:25:00.0000] <MikeSmith>
once you tell it you don't want to see a certain type/class of error, you won't see that error message for any further documents you check

[05:26:10.0000] <MikeSmith>
AryehGregor: details at http://keegan.st/2012/05/28/filtering-html5-validator-errors/

[06:13:05.0000] <hsivonen>
java.lang.NoSuchMethodError when lauching code in Eclipse that Eclipse was happy to compile

[06:14:09.0000] <Ms2ger>
Heh, Java

[06:22:48.0000] <Stevef_>
hixie: re quoting style, point me to your preferred and I will use it (emailed you offline about it yesterday as was not near an IRC client)

[06:24:01.0000] <Stevef_>
Mikesmith: are there any stats for the traditional validation service?  http://validator.w3.org/ i would imagine that would be doing a lot of business

[06:25:49.0000] <MikeSmith>
Stevef_: there probably are some stats but I've not seen them. I'll ask the systems team

[06:26:26.0000] <MikeSmith>
but would guess it's a few million page validations per day

[06:26:26.0000] <Stevef_>
mieksmith: thanks was suprised by the w3c nu markup service numbers

[06:26:34.0000] <MikeSmith>
yeah I was surprised too

[06:27:10.0000] <Stevef_>
yeah thats what i was thinking, well I have been promoting the nu service... ;-)

[06:37:59.0000] <hsivonen>
It turns out that I can't have GWT and HttpClient in the runtime deps at the same time

[06:46:32.0000] <david_carlisle>
trackbot, start telcon

[06:47:17.0000] <david_carlisle>
 oops sorry

[08:04:39.0000] <jgraham>
Hmm I just realised that the tests I was writing are supposed to only work in a top level browsing context, but seem to work fine in an iframe

[08:06:11.0000] <jgraham>
Hixie: If I have a non-top-level browsing context why don't the steps for storing (and hence restoring) a browsing context name happen?

[08:15:37.0000] <Stevef_>
q+

[08:16:33.0000] <MikeSmith>
Stevef_: wrong channel hombre

[08:20:32.0000] <Stevef_>
/me sorry

[08:54:31.0000] <dglazkov>
good morning, Whatwg!

[08:55:14.0000] <Hixie>
jgraham: good question, didn't realise iframes could change names

[08:56:05.0000] <jgraham>
Hixie: Well they have a browsing context and it has a name, right?

[08:56:26.0000] <jgraham>
So window.name="foo" in the iframe changes that name?

[08:56:31.0000] <Hixie>
yeah but i always thought it as the name in the <iframe name="">, didn't think of window.name for iframes

[08:56:36.0000] <Hixie>
purely an oversight on my part

[08:56:41.0000] <jgraham>
Ah, OK :)

[08:56:56.0000] <jgraham>
I was just checking that I didn't miss anything important here

[08:57:42.0000] <Hixie>
hsivonen: the <object> decision results in allowing non-sensical markup, it was in fact a bug in HTML4 that we intentionally fixed, so no, i have no plans to adopt that proposal. (see recent meme)

[08:58:35.0000] <Hixie>
jgraham: send a mail or file a bug or something? (i assume it's just a matter of removing a restriction in the spec?)

[08:58:58.0000] <jgraham>
Hixie: Sure, I think it is just removing a few words

[08:59:08.0000] <Hixie>
k

[08:59:44.0000] <Hixie>
Stevef_: i just meant the style everyone else uses, where quotes are indented with > rather than marked with "..."

[09:00:00.0000] <Stevef_>
hixie: ok got it

[09:00:04.0000] <Hixie>
thanks

[09:00:35.0000] <Hixie>
(it's mentioned near the end of the whatwg faq, fwiw, including some links to software that can fix the problem in some clients like outlook)

[09:02:01.0000] <jgraham>
Hixie: Bug filed, but I missed my window of oppertunity for the popup so now I will have to search for it

[09:02:16.0000] <Hixie>
heh

[09:02:32.0000] <odinho>
lol

[09:02:40.0000] <Hixie>
18470

[09:02:42.0000] <odinho>
fix (y)our ua ;-)

[09:02:46.0000] <Hixie>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18470

[09:02:55.0000] <Hixie>
and thanks :-)

[09:05:32.0000] <jgraham>
Thanks for finding my lost and lonely bug

[09:22:43.0000] <Hixie>
jgraham: it was easy, it was the one at the end of the list :-)

[11:01:13.0000] <Hixie>
good lord, unicode updated their cldr with a boatload of new data

[11:01:52.0000] <ojan>
MikeSmith: I'm told you're the one to talk to about problems with the w3.org email servers...is that true?

[11:02:09.0000] <Ms2ger>
Good first guess, at least

[11:02:44.0000] <ojan>
www-style email has been getting delayed by days for me and a few others for the past couple months

[11:03:00.0000] <ojan>
i've already talked to gmail folk, and it looks like the problem is on the w3.org side

[11:46:36.0000] <Hixie>
Lachy: what's the status on the about: spec?

[11:47:48.0000] <Lachy>
I don't know yet. I still need to figure out if the IETF draft can be salvaged.

[11:48:02.0000] <Ms2ger>
/me would assume not

[11:48:20.0000] <Hixie>
so I should ignore the about: registry that julian talks about in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18365 ?

[11:48:25.0000] <Lachy>
yes

[11:48:28.0000] <Hixie>
roger

[11:48:48.0000] <Lachy>
it's quick and easy to register it though, so it won't hurt. I just wouldn't consider it essential.

[11:49:17.0000] <Lachy>
Tell Julian he can register the schemes if he cares that much.

[11:49:34.0000] <Lachy>
s/schemes/tokens/

[11:49:44.0000] <Hixie>
oh, wow, that is simpler than i expected

[11:49:46.0000] <Hixie>
i can do those i guess

[11:50:11.0000] <Hixie>
any idea where i send it?

[11:51:21.0000] <Lachy>
yes, one sec.

[11:52:02.0000] <Lachy>
this form http://www.iana.org/cgi-bin/assignments.pl or send mail to iana⊙io

[11:52:14.0000] <Lachy>
I think that's the right address

[11:52:29.0000] <Hixie>
a form even! they've moved from the 80s to the 90s, i see

[11:52:35.0000] <Hixie>
thanks

[11:57:01.0000] <Lachy>
my only real problem with the registry now is that is implies some sort of exclusivity to registered tokens. Whereas about URLs should be regarded as non-resolvable addresses, which may have entirely context specific interpretations

[11:58:45.0000] <Lachy>
that would eliminate any possibility of conflict if two entirely independent specs happened to use the same token.

[12:02:05.0000] <Hixie>
ah

[12:13:52.0000] <Hixie>
ok i've gone through HTMLWG bugs filed up to august 1st and cloned any that looked like they were valid

[12:14:59.0000] <Hixie>
(who wants to bet the htmlwg never does that for the other direction yet continues to claim they care about fixing all known issue...)

[13:40:57.0000] <Ms2ger>
w3c: HTML WG Chairs announce editorial team for the W3C Canvas 2D Context specification http://t.co/u0FCQLpi

[13:46:05.0000] <jesusruiz>
hi, group!

[13:48:03.0000] <jesusruiz>
one question, i am writing a book and before publishing it I have to clarify one issue:

[13:48:10.0000] <jesusruiz>
Is it true the news that the WHATWG has separated from the W3C?

[13:48:51.0000] <jesusruiz>
I read on some website, which will be two html5

[13:49:40.0000] <smaug____>
/me kicks Google hard

[13:51:35.0000] <jgraham>
jesusruiz: The WHATWG and W3C will work on different versions of HTML, yes

[13:51:53.0000] <jgraham>
WHATWG will be focused on fixing bugs and adding new features

[13:52:07.0000] <jgraham>
W3C will be trying to keep lawyers happy

[13:52:34.0000] <jgraham>
By getting to Rec. which is needed for the W3C Patent Policy to kick in

[13:53:06.0000] <jesusruiz>
thanks jgraham

[13:53:19.0000] <jgraham>
That requires stability and an elaborate consensus-based decision making process

[13:53:40.0000] <jesusruiz>
much time working "together" for nothing, Mother of God O_o

[13:53:52.0000] <jgraham>
Or at least it seems to involve such an elaborate process, it isn't clear that it requires it

[13:55:03.0000] <jesusruiz>
:( another chaos in the web, return to the war: (

[13:55:55.0000] <jgraham>
Not really chaos

[13:57:16.0000] <jgraham>
There is only really a problem if the UA conformance requirements are different in the two versions (other than through W3C refusing to fix a bug in version 5 in the name of stability)

[13:58:03.0000] <jgraham>
Author conformance requirements being differnt affects validator authors and authors that read the spec (i.e. none of them)

[13:58:05.0000] <jesusruiz>
good, chaos may appear, if each browser uses one or another specification.

[13:58:34.0000] <jesusruiz>
 at least that support both specifications.

[13:59:28.0000] <jgraham>
It will be very surprising if browsers do differnt things; compatibility is good for the platform and so good for browser vendors

[13:59:38.0000] <jesusruiz>
but of course, the end is always the problem for webmasters.

[13:59:53.0000] <jgraham>
I expect most browser vendors to follow the WHATWG spec by necessity

[14:00:13.0000] <jgraham>
It will be more accurate and have more features that they need to keep up with the competition

[14:00:17.0000] <jesusruiz>
Yes, I agree. :)

[14:04:22.0000] <Hixie>
hsivonen: you around?

[14:06:47.0000] <jesusruiz>
Hixie: save the web! ;)

[14:07:08.0000] <jesusruiz>
W3C bad! :)

[14:07:23.0000] <Hixie>
not up to me, it's up to the vendors :-)

[14:07:26.0000] <Hixie>
MikeSmith: yt?

[15:29:04.0000] <Hixie>
hober: is image-set() going anywhere?

[15:30:15.0000] <hober>
Hixie: TabAtkins keeps saying he'll add it to CSS4 Images, but I don't know when he'll get to it.

[15:31:24.0000] <Hixie>
is it basically the same as srcset="" is now?

[15:31:27.0000] <Hixie>
but with cssy syntax?

[15:31:59.0000] <hober>
AFAIK it only handles the resolution case

[15:32:14.0000] <hober>
but that will depend on whatver TabAtkins puts in the draft

[15:32:57.0000] <Hixie>
ah ok

[15:32:58.0000] <hober>
as currently implemented, -webkit-image-set() only supports the resolution case, fwiw

[15:33:11.0000] <Hixie>
right

[15:33:38.0000] <hober>
on the css side of things, the art direction case is probably best handled with the existing mechanisms (MQs etc0

[15:34:03.0000] <Hixie>
yeah

[15:35:49.0000] <hober>
i think the only change i remember TabAtkins planning to make was to add the ability to specify a <color>

[15:36:11.0000] <hober>
(if the ua decides that *none* of the resources are to its liking, it could display the color instead)

[15:36:29.0000] <Hixie>
interesting

[15:41:44.0000] <zewt>
hober: or image-set(url(...), url(...), rgba(...))?

[15:43:08.0000] <Hixie>
more like image-set(url(...) 1x, url(...) 2x, rgba(...)) or some such, right?

[15:46:12.0000] <TabAtkins>
hober: I've already got it started, I just need to finish writing it out.  Expect it to show up this evening or tomorrow.

[15:46:28.0000] <TabAtkins>
Would have done it Tuesday, but was working on Flexbox and sizing things with fantasai instead.

[15:47:01.0000] <TabAtkins>
But yeah, planning on only doing the resolution stuff, because MQ does the other parts fine.

[15:47:28.0000] <zewt>
Hixie: yeah, I just mean that support for a color shouldn't be a special case

[15:47:29.0000] <TabAtkins>
<img srcset> just doesn't have an easy way to do MQs, so it has to reinvent them in its syntax.

[15:47:52.0000] <Hixie>
zewt: it's still special :-)

[15:47:53.0000] <zewt>
(note: i know nothing about image-set aside from the last page or so of IRC)

[15:48:03.0000] <TabAtkins>
hober: I'm still not sure what to do about 2x vs <resolution>

[15:48:04.0000] <Hixie>
TabAtkins: yeah

[15:48:17.0000] <Hixie>
it's amazing how HTML's syntax is constraining us

[15:48:25.0000] <Hixie>
but anyway

[15:48:29.0000] <hober>
TabAtkins: drop <resolution> obviously :)

[15:48:36.0000] <Hixie>
hober++

[15:48:38.0000] <othermaciej>
<resolution> is lame

[15:48:50.0000] <othermaciej>
no one will remember or understand what dppx units mean

[15:48:51.0000] <TabAtkins>
The "x" unit is just a synonym for "dppx".

[15:49:01.0000] <TabAtkins>
I'd prefer to just make it an explicit synonym.

[15:49:32.0000] <othermaciej>
and I think specifying dpi for this use case is not valuable

[15:49:44.0000] <TabAtkins>
...you're already specifying dpi.

[15:49:45.0000] <hober>
dp{i,cm,px} should just go away entirely; they're crazy

[15:50:01.0000] <othermaciej>
no, you're specifying a scale factor relative to "normal"

[15:50:10.0000] <TabAtkins>
Normal is 96dpi.

[15:50:32.0000] <othermaciej>
but there's no good reason to say 192dpi instead of 2x

[15:50:47.0000] <othermaciej>
and it may make you think you can say things like 200dpi, which will get you ugly blurry output

[15:51:16.0000] <TabAtkins>
It's probably less useful in this case, yeah.  But you're still specifying a resolution, so it's weird if you can't use the other resolution types.

[15:51:27.0000] <othermaciej>
or worse yet, it may make you think you should use the actual physical device dpi, which in this case would be utterly wrong

[15:51:32.0000] <hober>
but no one should ever, ever use the otheer resolution types

[15:51:53.0000] <hober>
s/ otheer// even :)

[15:52:05.0000] <othermaciej>
you might think you should say 326dpi instead of 192dpi

[15:52:18.0000] <hober>
exactly

[15:52:29.0000] <othermaciej>
for the iphone

[15:52:48.0000] <othermaciej>
css overloading dpi to mean something unrelated to physical dpi is a bad idea

[15:52:52.0000] <othermaciej>
and should not be propagated

[15:54:25.0000] <othermaciej>
192dpi is closer to the actual physical dpi of the original iPhone than to the Retina iPhone

[15:54:32.0000] <Hixie>
note that the display resolution is not necessarily just 1x vs 2x; consider browser zoom, or the retina macbook pro resolution setting

[15:55:12.0000] <hober>
right. image-set(foo 1x, bar 2x) just means that bar's resolution is twice that of foo's; it doesn't make any claims to foo or bar's actual resolution. the ua can then pick whichever would be best in the current circumstance

[15:55:22.0000] <othermaciej>
sure, you could have fractional zoom

[15:55:30.0000] <othermaciej>
but describing in in terms of dpi just confuses the issue

[15:55:47.0000] <TabAtkins>
hober: Well, that's no good.  That means you can't ever rely on auto sizing.

[15:56:00.0000] <TabAtkins>
"2x" needs to very strictly mean "this is 192dpi".

[15:56:09.0000] <hober>
auto sizing works fine

[15:56:18.0000] <othermaciej>
it doesn't mean "this is 192dpi", it means, "choose this when 2x scale is appropriate and downscale it by 2"

[15:56:32.0000] <Hixie>
othermaciej: 100% agree on dpi being pointlessly confusing here

[15:56:34.0000] <hober>
what othermaciej said

[15:56:40.0000] <Hixie>
like setting font-size in pt or width in cm

[15:56:46.0000] <TabAtkins>
Those two statements are equivalent.

[15:57:04.0000] <othermaciej>
no, because dpi could be taken as a statement about the image's intended true physical resolution

[15:57:12.0000] <TabAtkins>
Because the 1x scale means "this is 96dpi".

[15:57:18.0000] <hober>
no it doesn't

[15:57:20.0000] <othermaciej>
except to people who know the insane CSS definition of DPI

[15:57:31.0000] <TabAtkins>
You can *think* your iamge is something else, but you're wrong.  It's 96dpi by definition. ^_^

[15:57:33.0000] <othermaciej>
(and believe it)

[15:57:41.0000] <TabAtkins>
Hixie: You coming to my desk?

[15:57:57.0000] <othermaciej>
it's 96 dots per CSS inch, not 96 dots per inch

[15:58:21.0000] <othermaciej>
a normal person would not think that "dpi" means "multiply by 96"

[15:58:37.0000] <othermaciej>
so calling that unit dpi is bordering on evil

[15:58:53.0000] <othermaciej>
furthermore, there is no particular case where it is helpful or convenient to multiply by 96

[15:59:06.0000] <TabAtkins>
What are you talking about?  There's no multiplication by 96.

[15:59:06.0000] <othermaciej>
and it makes it harder to see which values represent an integral scale factor

[15:59:33.0000] <TabAtkins>
"dots per CSS inch" is approximately the same as "dots per physical inch", and the approximation gets closer as resolutions go up.

[15:59:47.0000] <othermaciej>
it is in no way approximately the same

[16:00:00.0000] <othermaciej>
the iPhone has 192 dots per css inch and 326 dots per physical inch

[16:00:07.0000] <TabAtkins>
At a normal zoom factor it is.

[16:00:22.0000] <othermaciej>
192 is not approximately the same as 326

[16:02:44.0000] <hober>
If I've done the math right, I think 1 CSS liter is 37,795 cubic pixels.

[16:03:23.0000] <othermaciej>
CSS liter makes about as much sense as CSS dpi :-)

[16:03:43.0000] <hober>
(cubic css pixels, of course.)

[16:03:46.0000] <hober>
yeah, exactly

[16:14:06.0000] <zewt>
cool, that thread is now totally derailed

[16:14:10.0000] <zewt>
(ugh)

[16:15:12.0000] <hober>
zewt: the lazy blob thread?

[16:15:19.0000] <zewt>
yeah


2012-08-03
[17:17:26.0000] <MikeSmith>
Hixie: here now

[17:50:11.0000] <roc>
at least I don't have to take responsibility for the CSS "dpi" unit

[17:51:08.0000] <TabAtkins>
Who *is* responsible for that?

[17:51:16.0000] <roc>
I don't know

[17:51:23.0000] <roc>
can we not implement it and then take it out of the spec?

[17:51:54.0000] <roc>
ddpx is a dumb name but at least it makes some sense

[17:52:46.0000] <TabAtkins>
dppx. ^_^

[17:53:02.0000] <roc>
I reset my case

[17:53:15.0000] <TabAtkins>
I suspect it falls out of the image-resolution property, which is specced because CSS printers implemented it unprefixed.

[17:53:41.0000] <TabAtkins>
I'm just gonna define "x" to be a synonym for "dppx".

[17:53:50.0000] <TabAtkins>
And we'll see who screams.

[17:55:19.0000] <TabAtkins>
Oh, roc, while you're here, I had a question about your comments on element() to Birtles.

[17:55:52.0000] <TabAtkins>
In particular, what do you see as clashing about the use of element() as <image> and as a more generic element reference?

[17:57:06.0000] <roc>
mask:url(foo.svg#abc)

[17:57:19.0000] <roc>
er wait

[17:57:24.0000] <roc>
that's not what you were asking about

[17:57:35.0000] <roc>
mask:element(#abc)

[17:58:29.0000] <roc>
and suppose the element with the mask style is not an ancestor of the #abc element

[17:58:53.0000] <roc>
as currently specced I think that matches according to CSS Images and does not match according to the SVG proposal

[17:59:21.0000] <TabAtkins>
Ah, I see.  So it's valid as an <image>, but not as a mask reference.

[17:59:40.0000] <TabAtkins>
Okay, so then we probably do want a separate function for "refer to an element" that doesn't interpret it as an image.

[17:59:49.0000] <TabAtkins>
Like select() or something.

[17:59:52.0000] <roc>
or

[18:00:24.0000] <roc>
well

[18:00:32.0000] <roc>
yes, that's probably for the best

[18:00:49.0000] <roc>
descendant() might be a better name

[18:01:12.0000] <roc>
maybe we're not talking about the same thing

[18:01:42.0000] <roc>
I think basically you want a version of element() that matches only within the subtree of the styled element. Possibly that could be achieved with extended selector syntax,  but a different CSS value is probably better

[18:01:59.0000] <roc>
that could be a CSS image value and then SVG could just use it

[18:02:23.0000] <TabAtkins>
Or, wait, it's actually not a problem I think?

[18:03:00.0000] <TabAtkins>
if element(#abc) points to a non-child, or a child that's not a <mask>, it's an <image>.  If it points to a <mask> child, it's a mask reference.

[18:03:17.0000] <TabAtkins>
The two should be mutually exclusive, since <mask> doesn't provide a paint source.

[18:05:36.0000] <roc>
that seems fragile

[18:06:19.0000] <TabAtkins>
Potentially, yeah.

[18:07:04.0000] <TabAtkins>
So, back to select().  If you allow the same fragment thing that document.find() does, it would be easy.  "mask: select(> .foo);"

[18:24:17.0000] <TabAtkins>
hober: Any opinion on what the interaction between image-set("foo" 2x) and 'image-resolution' should be?

[18:29:27.0000] <TabAtkins>
hober: Right now, I have image-set() defined as setting the "intrinsic resolution" of the image, but that doesn't play well with the current initial value of "image-resolution".

[18:30:32.0000] <TabAtkins>
It might make sense to change the initial value to "auto", which means "1x, unless CSS says otherwise".

[23:22:19.0000] <hsivonen>
Hixie: pong

[23:30:00.0000] <Hixie>
hsivonen: your input on this thread would be helpful: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0004.html

[07:01:53.0000] <jgraham>
So if window A opens window B opens window C and B closes before any script can run in C, how do I get a reference from C to A?

[07:18:46.0000] <smaug____>
ugh, "please attach a minimal testcase" -> a zip file containing for example jQuery :/

[07:20:14.0000] <zewt>
smaug____: to too many people, jQuery is "default" :|

[07:20:33.0000] <jgraham>
smaug____: You know it isn't possible to write js without jQuery, right?

[08:24:06.0000] <GPHemsley>
Hixie: So... why does the spec use a combination of AmE and BrE?

[08:25:59.0000] <Ms2ger>
It should be using en-US

[08:31:32.0000] <GPHemsley>
Ms2ger: 'organisation' is not en-US

[08:33:02.0000] <Ms2ger>
-s- seems to be used only for autocomplete, all other occurrences use -z-

[08:33:51.0000] <GPHemsley>
Ms2ger: And that was the precise instance I was looking at :)

[08:34:06.0000] <Ms2ger>
It's the only you could be looking at! ;)

[08:34:19.0000] <GPHemsley>
Ms2ger: At least I'm not seeing things!

[08:34:56.0000] <Ms2ger>
/me is glad he svn up'd the repo before claiming there was no such spelling in the spec

[08:35:17.0000] <GPHemsley>
:)

[08:39:01.0000] <Hixie>
GPHemsley: purely an oversight, please file bugs (if it's a keyword to be implemented, mark the bug "blocker")

[08:39:06.0000] <Hixie>
or send mail

[08:39:11.0000] <GPHemsley>
k

[08:39:26.0000] <Hixie>
should all be en-US

[08:39:47.0000] <Hixie>
the problem is that i speak en-GB and keep forgetting which is which

[08:39:57.0000] <Hixie>
due to spending too much time in the US

[08:41:06.0000] <micheil>
Hixie:  I thought you spoke en-HIXIE?

[08:41:14.0000] <micheil>
or was that someone else here?

[08:41:18.0000] <Hixie>
en-GB-x-Hixie :-)

[08:41:37.0000] <micheil>
that's it! A custom dialect of english

[08:41:41.0000] <Ms2ger>
Good morning dglazkov

[08:41:42.0000] <micheil>
;)

[08:41:54.0000] <Ms2ger>
Sure would be weird if someone else here spoke en-GB-x-Hixie

[08:42:01.0000] <dglazkov>
\o/

[08:42:36.0000] <GPHemsley>
Bug 18482

[08:46:16.0000] <niloy>
We request data from a servlet using ajax and parse the data as JSON, but when the JSON size is large, the UI hangs, can someone suggest any solution?

[08:48:35.0000] <GPHemsley>
micheil: 'Tis an idiolect, indeed.

[08:49:14.0000] <micheil>
heh, I remember there being a similar discussion a few months back..

[08:50:15.0000] <micheil>
niloy: you may wish to ask that in, say, ##javascript (pretty sure these guys are doing spec stuff)

[09:07:04.0000] <Velmont>
timeless: http://my.opera.com/desktopteam/blog/2012/08/03/summer-core-update << has updated websocket now. -- So then /that/ blocker for irccloud is removed at least :P

[10:32:04.0000] <TabAtkins>
Any examples of some popular super-early polyfills damaging out ability to change a feature?

[10:35:08.0000] <Velmont>
Where are you going to use it? :]

[10:35:31.0000] <Velmont>
(I don't know any examples, for the record)

[10:35:38.0000] <Ms2ger>
var indexedbDB = window.indexedDB || window.webkitIndexedDB || window.moz .....?

[10:36:02.0000] <Velmont>
Ms2ger: What about it?

[10:36:08.0000] <Ms2ger>
https://bugzilla.mozilla.org/show_bug.cgi?id=770844

[10:38:19.0000] <TabAtkins>
Oh, that's a different type of issue.

[11:38:42.0000] <hober>
is http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-resize really the most up-to-date documentation of the resize event?

[11:41:37.0000] <Ms2ger>
Probably

[11:42:59.0000] <hober>
sadface

[12:06:38.0000] <TabAtkins>
heycam|away: Is there any particular reason WebIDL doesn't let you nest constructors underneath another object?

[13:13:11.0000] <TabAtkins>
hober: How does the spec for image-set() look to you? http://dev.w3.org/csswg/css4-images/#image-set-notation

[13:14:47.0000] <hober>
syntax nit: I think you mean * where you have +

[13:15:05.0000] <TabAtkins>
No, that was intentional.  There doesn't seem to be any use for an image-set() with only a single argument, is there?

[13:15:45.0000] <hober>
fair enough

[13:16:01.0000] <hober>
why [ <url> | <string> ] instead of <image>?

[13:16:05.0000] <TabAtkins>
I suppose maybe it could be useful if you *only* want to serve a 2x image...

[13:16:13.0000] <TabAtkins>
Because <image> covers things like gradients.

[13:16:52.0000] <hober>
image-set(image(......) 1x, image(....) 2x) should be fine, don't you think?

[13:17:17.0000] <TabAtkins>
Oh, right, yes.  Hmm.  Let me do some grammar hackery to make that work.

[13:17:45.0000] <hober>
and of course you know my feelings on <resolution>

[13:17:53.0000] <hober>
otherwise this all looks fine

[13:18:00.0000] <TabAtkins>
And the reverse, too. image(image-set(...), image-set(...))

[13:18:03.0000] <TabAtkins>
kk

[13:18:10.0000] <hober>
right (the reverse should work)

[13:18:14.0000] <zewt>
TabAtkins: what benefit is there to restricting to 2+? seems like it'd do nothing but be annoying, heh

[13:18:39.0000] <TabAtkins>
zewt: The entire point of image-set() is to provide multiple versions of an image.

[13:18:43.0000] <hober>
is your algorithm always going to pick the same asset that <img srcset=""> would given the same arguments?

[13:19:05.0000] <zewt>
TabAtkins: that's not an explanation for *requiring* it, unless there's something inherent to it that would make it not work at all

[13:19:16.0000] <TabAtkins>
hober: There's no requirement there, but I don't see why it wouldn't.  If HTML already defines something that I can hook, I'm willing to.

[13:19:31.0000] <zewt>
eg. if I'm editing image-set in existing CSS and I want to remove or comment out an entry, why would you force me to rewrite it without image-set?

[13:19:40.0000] <zewt>
(if it happens to reduce it to one item)

[13:20:00.0000] <TabAtkins>
zewt: Good point.  That tips me over the edge.  I'll change to *.

[13:20:04.0000] <zewt>
sounds sort of like something in Java that aggravated me to no end: unreachable code is a fatal error

[13:20:14.0000] <hober>
TabAtkins: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset

[13:21:08.0000] <hober>
sorry, this is the relevant link

[13:21:09.0000] <hober>
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates

[13:22:34.0000] <TabAtkins>
hober: Hm, that algorithm seems unnecessarily restrictive.

[13:22:53.0000] <TabAtkins>
By my reading, it prevents you from ever choosing a low-res image under low-speed connections.

[13:23:05.0000] <hober>
see step 16

[13:23:19.0000] <TabAtkins>
Oh, gotcha.

[13:25:07.0000] <TabAtkins>
Hm, it appears that my algorithm and HTML's are functionally identical, actually.

[13:25:33.0000] <TabAtkins>
However, a note that it should match <img srcset> would be appropriate.

[13:26:17.0000] <zewt>
TabAtkins: not to state the obvious or anything, but it's infinitely better to use the same algorithm than to declare it twice and assert that they're the same :)

[13:26:37.0000] <TabAtkins>
Ooh, wait - it appears that HTML decides definitely on the candidate before trying to resolve the URL, and doesn't change its mind even if the URL is an invalid image.

[13:26:59.0000] <hober>
that's what i would expect image-set() to do too

[13:27:14.0000] <hober>
the whole idea is that asset selection happens without having to fetch any assets

[13:27:20.0000] <zewt>
personally i'd find it weird if it had magic multi-fetch recovery stuff

[13:27:35.0000] <hober>
if you want magic multi-fetch fallback stuff, use image()

[13:27:45.0000] <TabAtkins>
Really?  I have it specced to have a similar behavior to image(), where the UA orders the resources as it wants, then gets the first one that successfully decodes as an image.

[13:28:03.0000] <TabAtkins>
You can't actually use image() here, since your fallback is "use the next-best image".

[13:28:15.0000] <TabAtkins>
Rather, "your desired fallback".

[13:28:47.0000] <TabAtkins>
And you can't predict ahead of time how the UA will order the resources.

[13:29:48.0000] <hober>
each image-set() should only ever result in one http request; if it turns out to be invalid, you get an invalid image

[13:29:58.0000] <TabAtkins>
That seems quite suboptimal.

[13:30:01.0000] <hober>
if that doesn't work, image(image-set(), image-set(),...)

[13:30:30.0000] <TabAtkins>
...that wont' work.  It'll just request the same image again, presumably, unless you want to assume that "I already tried this once" is a factor in the resource selection algorithm.

[13:30:30.0000] <zewt>
hober: wouldn't that not work since there's no way for the second image-set to say "everything in the first minus whatever was picked first"?

[13:30:35.0000] <TabAtkins>
Plus it's very verbose.

[13:31:05.0000] <TabAtkins>
Telling someone to repeat their entire image-set() N times, where N is the number of things in the image-set(), is just user-hostile.

[13:31:08.0000] <hober>
I woudn't expect those two image-set()s to be the same

[13:31:24.0000] <hober>
or you can do it with image-set(image() 1x, image() 2x)

[13:31:43.0000] <TabAtkins>
Again, that's something *different*.

[13:31:48.0000] <zewt>
personally I find the idea of browsers trying to recover from being given bad urls unusual

[13:31:56.0000] <hober>
zewt: right

[13:32:12.0000] <hober>
zewt: it's the purpose of image(), but not of image-set(), so it would surprise me if image-set() was magic in that way

[13:32:24.0000] <zewt>
(i'd rather see an "X" or something, instead of have it silently "recover", at the expense of extra network requests and presumably a suboptimal image being shown)

[13:32:43.0000] <zewt>
does that happen with background-image: url(), url(), ...?

[13:32:56.0000] <TabAtkins>
Multiple bg images are stacked, not fallbacks.

[13:33:12.0000] <TabAtkins>
(And an invalid image in CSS is just invisible.)

[13:36:49.0000] <zewt>
unrelatedly, anyone want to give me a reason not to put *[hidden] { display: none !important; } in my stylesheet? heh

[13:37:00.0000] <TabAtkins>
No, go for it.

[13:37:07.0000] <TabAtkins>
No need for the *, though.

[13:37:14.0000] <TabAtkins>
Save a byte for your users. ^_^

[13:37:15.0000] <zewt>
rather annoying that without it, every display: rule has to be in its own :not([hidden]) rule

[13:37:52.0000] <TabAtkins>
It's unfortunate that UA !important has become de-facto a more powerful level than author or user !important.

[13:38:06.0000] <zewt>
(and a bit strange that I need to work around it at all; I wish there was a separate boolean CSS rule to hide things that takes precedence over display)

[13:38:21.0000] <TabAtkins>
zewt: Yeah, that was clearly a mistake on our part early on.

[13:38:33.0000] <TabAtkins>
Definitely one of the time-travel fixes in CSS.

[13:38:35.0000] <zewt>
is there anything preventing adding something like that now?

[13:39:21.0000] <TabAtkins>
No, not particularly.  Only inertia, plus possibly pushback from impls in the group who don't want to add something "unnecessary" because they have no authoring experience.

[13:39:33.0000] <zewt>
heh

[13:40:00.0000] <zewt>
@hidden is a big improvement, but everyone having to learn how it interacts with display is unfortunate

[13:40:02.0000] <TabAtkins>
But I'm off-and-on working on a 'display' spec, and might as well fit that into the same thing.

[13:41:35.0000] <zewt>
also the fact that webkit transitions became pretty much de-facto everywhere is ... annoying

[13:41:52.0000] <timeless>
Velmont: thanks, why didn't the operaupdater.exe tell me about it?

[13:41:55.0000] <TabAtkins>
hober: Want to start a thread about the fallback thing?  If we don't do any fallback within image-set(), then there's no real reason to include the color, except perhaps just avoiding the verbosity of a wrapping image().

[13:42:01.0000] <zewt>
still can't figure out any way to synchronously skip transitions

[13:42:11.0000] <timeless>
/me was running 11.52

[13:42:13.0000] <TabAtkins>
transition-duration: 0 !important

[13:42:14.0000] <hober>
TabAtkins: which is fine by me (not including the color)

[13:42:38.0000] <TabAtkins>
hober: Well, obviously, since you don't want to change your impl. ^_^

[13:42:44.0000] <hober>
heh

[13:42:45.0000] <zewt>
i've tried unsetting the transition while i make some change I don't want to transition, then setting it back, but it still does the transition

[13:42:50.0000] <TabAtkins>
Anyway, start a thread so we can discuss it, now that it's written up.

[13:43:04.0000] <hober>
i'll probably start two or three threads

[13:43:06.0000] <TabAtkins>
zewt: Do you flush style in between those?

[13:43:09.0000] <TabAtkins>
hober: Cool.

[13:43:14.0000] <hober>
(the fallback thing, the <resolution> thing, the <color> thing)

[13:43:21.0000] <zewt>
only way i've found is something like clear transition, setTimeout(function() { make the change, restore the transtiion }, 0), which of course isn't synchronous

[13:43:35.0000] <zewt>
TabAtkins: not sure what that means

[13:43:47.0000] <TabAtkins>
hober: I think the interesting use-case of providing printer-friendly versions justifies the <resolution>. ^_^

[13:43:49.0000] <timeless>
Velmont: so... the updater gave me 12.01

[13:43:56.0000] <timeless>
... which isn't the same as 12.50

[13:44:18.0000] <TabAtkins>
zewt: Browsers queue up style changes until they're forced to resolve them (or enough time passes that they need to resolve them for rendering).

[13:44:41.0000] <TabAtkins>
zewt: So doing an operation that requires accurate style information flushes the style queue, which is required for some hackery around transitions/animations to work properly.

[13:44:56.0000] <timeless>
oh, 12.50 is a dev preview thing

[13:45:24.0000] <zewt>
TabAtkins: what's good for triggering that? will getComputedStyle do it?

[13:45:40.0000] <jamesr_>
yeah

[13:45:44.0000] <jamesr_>
man i need to revive that proposal

[13:45:47.0000] <zewt>
(well, I know it'll force a style update, but I don't know if it'll do the job with transitions in the mix)

[13:45:52.0000] <TabAtkins>
Yeah, I think so.  Tony Gentilcore put up a fairly comprehensive list of what works in WebKit, and the list should be pretty similar across browsers.

[13:46:01.0000] <jamesr_>
i'm not 100% on that in gecko

[13:46:16.0000] <jamesr_>
in WebKit that'll flush it all out

[13:46:53.0000] <zewt>
oddly, firefox is the only browser I hit where the setTimeout() hack didn't work (on code that worked in chrome and opera)

[13:47:16.0000] <zewt>
(the site is pretty mobile safari-centric so I couldn't spend much time poking at it, though)

[13:47:29.0000] <hober>
TabAtkins: the print case is more reasonably handled with the existing scale factor. image-set(foo.png 1x, bar.png 2x, baz.png 6x)

[13:48:03.0000] <timeless>
Velmont: so, the irccloud app still renders wrong (it loads at least, which is nice)

[13:48:06.0000] <zewt>
hober: how? are you just going to provide an arbitrarily blown-up image and hope it's both big enough for printing and not unnecessarily big? heh

[13:48:13.0000] <timeless>
specifically, the bottom of irccloud is outside the window edge

[13:48:19.0000] <zewt>
afk a few

[13:48:20.0000] <timeless>
and that's where the user input field is :(

[13:49:06.0000] <TabAtkins>
zewt: It's weird that setTimeout() didn't work.  I thought everyone flushed style when they returned to the event queue.

[13:49:37.0000] <jamesr_>
no

[13:49:42.0000] <jamesr_>
we defer as much as possible

[13:49:53.0000] <jamesr_>
ideally we don't flush style until somebody asks via CSSOM or we go to paint

[13:49:56.0000] <TabAtkins>
Huh, okay.

[13:50:07.0000] <TabAtkins>
I clearly know nothing.

[13:50:10.0000] <jamesr_>
i've made this gradually more deferred in WebKit over the past year+

[13:50:16.0000] <jamesr_>
it used to flush after every return from JS

[13:50:58.0000] <jamesr_>
gecko has a repeated style flush timer, i don't know if they also flush eagerly after returning from JS

[13:53:21.0000] <zewt>
of course, the problem is that this is script-visible (due to transitionend)

[13:53:30.0000] <zewt>
when this stuff breaks, i don't get the event and things break

[13:54:06.0000] <timeless>
hey, anyone here familiar w/ the http portion of websocket initialization?

[13:54:21.0000] <timeless>
how much of `upgrade: websocket` is case sensitive?

[13:54:31.0000] <timeless>
and which document(s) specify that?

[13:55:28.0000] <zewt>
rfc6455?

[13:56:19.0000] <TabAtkins>
hober: I've added your two issues to the draft.

[14:01:18.0000] <timeless>
zewt: 4.2.1 point 3

[14:01:24.0000] <timeless>
specifically, which is what i needed

[14:01:48.0000] <timeless>
it's a long document ...

[14:02:30.0000] <zewt>
welcome to ietf specs

[14:10:03.0000] <TabAtkins>
hober: What do you think about the situation where you have image-set(image-set(foo 1x) 2x)?

[14:10:22.0000] <hober>
what's the problem?

[14:10:33.0000] <TabAtkins>
Valid? And if so, what does it mean?

[14:11:02.0000] <TabAtkins>
And if not, is it okay to require impls to recurse down the tree of references to ensure that there's no image-set() anywhere inside of an image-set()?

[14:11:06.0000] <hober>
foo gets selected for the inner image-set(), and its intrinsic width doesn't get scaled down. then the inner image-set() is selected for the outer image-set(), and its intrinsic size gets scaled by 0.5

[14:11:26.0000] <TabAtkins>
...so if they were both 2x, it would get scaled twice?  That seems bad.

[14:12:00.0000] <hober>
i don't think it makes much sense for authors to do this, but i don't think it necessarily has to be made invalid.

[14:12:08.0000] <hober>
it's like other valid-but-kinda-nonsensical things

[14:12:37.0000] <TabAtkins>
I'd like to make sure, as much as possible, that valid things are interpreted sanely.

[14:12:54.0000] <TabAtkins>
In other words, stupid results should be because of stupid actions, not unintentional stupid interactions on our side.

[14:13:18.0000] <hober>
sure. and in this case, stupid results are as a result of stupid actions; the interpretation on our side is totally reasonable given the input

[14:13:25.0000] <hober>
gigo

[14:14:10.0000] <TabAtkins>
I don't particularly see how image-set(image-set('foo' 2x) 2x) meaning the same as image-set('foo' 4x) is reasonable on our part.

[14:14:25.0000] <zewt>
how isn't it? it seems like the logical result

[14:14:54.0000] <TabAtkins>
Only if you interpret the "2x" as meaning "halve the specified size", rather than "set the intrinsic resolution to 2 dots per px".

[14:15:46.0000] <hober>
again, we come back to the <resolution> craziness :)

[14:16:00.0000] <TabAtkins>
Your interpretation is just stilly, though. ^_^

[14:16:14.0000] <hober>
this is clearly something on which we disagree. :)

[14:19:31.0000] <TabAtkins>
Anyway, if the effect is "nonsensically stack the multipliers", I'd rather just make it invalid.

[15:03:05.0000] <poop>
Is it valid in html5 to have <ns:customel>text</ns:customel>? I know that declaring namespaces in the html element with @xmlns is unsupported, but what about actually using the elements themselves?

[15:03:28.0000] <TabAtkins>
No, those are also invalid.

[15:03:45.0000] <TabAtkins>
(Because they can't be represented in the XML serialization.)

[15:04:00.0000] <poop>
TabAtkins: thanks. what do you mean by that?

[15:05:17.0000] <gsnedders>
<ns:customel> creates an element whose namespace is "http://www.w3.org/1999/xhtml" and whose local name is "ns:customel".

[15:05:23.0000] <gsnedders>
Local names cannot contain colons.

[15:05:26.0000] <TabAtkins>
What I said. ^_^  If you parse as HTML, it knows nothing about namespaces, so it would just set the tagname to "ns:customel".  But this can't be exported back into XML - you can't have element names with : in them.  So, to maintain the DOM Consistency Principle, we make it invalid in HTML.

[15:06:52.0000] <poop>
TabAtkins: is there a spec for how this will be handled by UAs despite being invalid?

[15:07:09.0000] <gsnedders>
poop: Yes, the Parsing HTML Documents section.

[15:07:10.0000] <hober>
poop: the HTML spec

[15:07:12.0000] <gsnedders>
(in HTML/HTML5)

[15:27:56.0000] <Hixie>
poop: what's your specific use case? (what are you trying to do?)

[15:34:38.0000] <poop>
Hixie: oh, hi there. :)

[15:35:06.0000] <poop>
ummm, well i'm juust exploring possibilities for right now... I mean, I would like to have more semantic markup than what HTML natively provides.

[15:35:46.0000] <Hixie>
why?

[15:35:53.0000] <poop>
tags like <x:comment> and <avatar> and stuff, so that i don't get to have such messy </div></div></div>

[15:35:56.0000] <TabAtkins>
Semantics are a contract between you and the consumer.  Custom elements thus have zero semantics.

[15:35:58.0000] <poop>
it's hard to work with.

[15:35:58.0000] <Hixie>
(what do you mean by "semantic"?)

[15:36:17.0000] <TabAtkins>
Every custom element is semantically equivalent to a <div> or <span>.

[15:36:18.0000] <Hixie>
<x:comment> has an element in HTML, it's <article>

[15:36:22.0000] <poop>
Hixie: well one it makes my markup easier and more maintainable and legible.

[15:36:42.0000] <Hixie>
for <avatar> you mean like a version of <img>?

[15:37:11.0000] <poop>
Hixie: shouldn't that be reserved for main centerpieces of webpages? I'm talking about for like a comment thread on a blog post

[15:37:17.0000] <poop>
Hixie: yes, exactly.

[15:37:49.0000] <Hixie>
poop: the "semantic" of an element is derived from what the spec says the element means, not from the tag name

[15:37:57.0000] <Hixie>
poop: i recommend reading the spec's section on <article> :-)

[15:38:26.0000] <poop>
in one sense it is a contract between me and the consumer.  on the other hand its a nicer and more elegant one between me and myself.  interacting with the dom in js willl be more concise and i could even modify the ua with a browser ext. and recommend thatmy users install it.

[15:38:41.0000] <poop>
Hixie: okay, but what about <img>?

[15:38:48.0000] <poop>
and <avatar>?

[15:38:56.0000] <Hixie>
if you just want something for yourself, I recommend making up your own language, and then having a script that converts it to HTML

[15:39:03.0000] <Hixie>
that's what i do sometimes

[15:39:18.0000] <TabAtkins>
If you're worried about code naming, that's not semantics.  ^_^  Do what Hixie says - use a preprocessor to convert your private language into vanilla HTML.

[15:39:29.0000] <TabAtkins>
And paper over the differences in DOM with some helper functions.

[15:39:30.0000] <poop>
Hixie: oh really? have you ever written about it more extensively than you're likely to do here in IRC anywhere?

[15:39:49.0000] <Hixie>
e.g. the HTML spec itself is written in a kind of frankenstein's monster variant of HTML that I pipe through half a dozen scripts

[15:39:57.0000] <poop>
Hixie: i'm interested in the implementation details... :)

[15:40:09.0000] <Hixie>
the implementation is embarassingly ugly

[15:40:22.0000] <poop>
Hixie: ah, ok.

[15:41:21.0000] <Hixie>
but the principle is sound :-)

[15:41:24.0000] <poop>
but still, debugging isn't so easy when when you open your page in the browser for rendering the closing tags are a bunch of </div></div></div>s

[15:41:30.0000] <TabAtkins>
Just use Python or something - it's got decent dom-style implementations.

[15:41:48.0000] <poop>
TabAtkins: I've been reluctant to invest in larning python.

[15:41:49.0000] <Hixie>
poop: we've mostly removed the need to use <div> these days

[15:41:56.0000] <Hixie>
poop: i almost didn't include <div> in HTML actually

[15:42:05.0000] <Hixie>
but people threated to hit me

[15:42:08.0000] <poop>
Hixie: oh really?

[15:42:10.0000] <Hixie>
threatened

[15:42:13.0000] <poop>
thatwould've been awesome.

[15:42:27.0000] <Hixie>
note that <avatar> vs <img> doesn't involve any </div>s :-P

[15:43:15.0000] <gsnedders>
TIL: web developers are sadists, willing to do anything to keep their elements.

[15:43:25.0000] <TabAtkins>
Reasonable layouts still generally require <div>s.  Particularly since there's no <content> element. ^_^

[15:43:38.0000] <TabAtkins>
gsnedders: Masochists, you mean?

[15:43:45.0000] <Hixie>
TabAtkins: yeah man, when's css gonna fix that :-P

[15:43:47.0000] <TabAtkins>
Oh, the hitting of Hixie.

[15:43:58.0000] <TabAtkins>
Hixie: Man, I don't know.  We gotta get this shit together.

[15:44:24.0000] <poop>
Hixie: no, but it is still more readable.

[15:45:04.0000] <TabAtkins>
poop: In my experience as a webdev, if your page is broken up into components that are responsible for emitting their own HTML, you rarely have very much nesting in any single chunk of HTML.

[15:45:18.0000] <TabAtkins>
(Even if the generated output stacks </div>s like they're going out of style.)

[15:45:20.0000] <Hixie>
poop: i seriously recommend making your own language and having a tool to convert from one to the other

[15:45:24.0000] <Hixie>
anyway, i gotta run. bbl.

[15:45:33.0000] <poop>
and i don't have to use <-i-m-g- -c-l-a-s-s-=-"-a-v-a-t-a-r-"- -/-> and i can just say <-a-v-a-t-a-r->

[15:46:51.0000] <gsnedders>
TabAtkins: Yeah, the hitting of Hixie was what I meant.

[15:47:40.0000] <TabAtkins>
/me still would find it amusing to have <font> as a holder for @style, and it invalid everywhere else.

[16:01:05.0000] <zewt>
TabAtkins: though I'll confess to having considered using a bogus element name just to have a generic inline-block container, heh

[16:01:23.0000] <zewt>
thus far I've resisted

[16:01:25.0000] <TabAtkins>
<x-ib>

[16:04:25.0000] <zewt>
(personally I have no idea how you'd write a webpage without <div>, unless it means using <span> and stuffing display:block on it, and I don't know that that actually improves anything)

[16:04:42.0000] <TabAtkins>
It doesn't, obviously. ^_^

[16:05:08.0000] <TabAtkins>
I've done div-less development before.  You can get surprisingly far if you're lucky with the kinds of display you want.

[16:05:12.0000] <zewt>
i've briefly considered only using span (or div) for layout like that, and dismissed it as doing nothing but making me write more css rules

[16:05:59.0000] <zewt>
well, most of my pages are the sort that involve an artist handing me a PSD, heh

[16:06:23.0000] <zewt>
(for work, anyway)

[16:06:44.0000] <TabAtkins>
Yeah, for that case you're almost certainly going to end up with <div>s immediately.

[16:07:00.0000] <TabAtkins>
But doing it with the minimum of junk was always a fun challenge to me.

[16:08:15.0000] <zewt>
special thanks for random hover on gmail saying in big letters: Glenn Maynard (you)

[16:08:22.0000] <zewt>
apparently google thinks i need the reminder

[16:08:47.0000] <TabAtkins>
We're not saying you're dumb, but...

[16:09:20.0000] <zewt>
also gmail dropping the colored name thing is really annoying, since now I can't tell which Ian a post is from, from the message index

[16:09:28.0000] <zewt>
used to be all Hixies were the same color

[16:09:29.0000] <TabAtkins>
Man, I know.

[16:09:53.0000] <zewt>
it's the basic design flaw of web apps: when somebody decides it's time to "upgrade", you don't get any choice in the matter


2012-08-04
[18:19:00.0000] <MikeSmith>
Hixie, you pinged me yesterday

[18:51:13.0000] <heycam>
TabAtkins, do you mean like `new Something.OtherThing(…)?`?

[18:52:02.0000] <heycam>
TabAtkins, hasn't come up so far. but also I think you can just write a static operation and using new on it will just work.

[19:31:09.0000] <TabAtkins>
heycam: Yes, that's it.

[19:32:00.0000] <TabAtkins>
heycam: I'm not sure how it would work with a static operation.  I could certainly define it to work as a constructor, but the definition of the returned type would presumably still have to be an interface, and thus would appear on the window, right?

[19:32:38.0000] <heycam>
TabAtkins, oh I see, so you want to have the interface object itself under a different object, not just an additional constructor

[19:33:01.0000] <TabAtkins>
Well, I suppose it's not important to hide the interface object.

[19:33:12.0000] <TabAtkins>
The point of putting it under another object is to curb verbosity, is all.

[19:33:26.0000] <TabAtkins>
But if the "real" interface exists and has a long name, that's irrelevant I suppose.

[19:33:33.0000] <heycam>
TabAtkins, because you get to use a shorter name?

[19:33:35.0000] <TabAtkins>
Yeah.

[19:33:55.0000] <heycam>
new Element.A("blah")

[19:33:56.0000] <TabAtkins>
Things like the constructors for the css value types in the new om api.

[19:33:58.0000] <heycam>
that kind of thing?

[19:33:59.0000] <TabAtkins>
Yup.

[19:34:43.0000] <heycam>
will all these constructors return an object that inherits from the outer thing on which you're putting the constructor?

[19:34:50.0000] <TabAtkins>
No.

[19:34:59.0000] <TabAtkins>
The outer thing will pretty much just be a namespace object.

[19:35:38.0000] <TabAtkins>
The plan is for a CSS interface, which is like navigator or something - a place to stash CSS-related things so they don't end up on window.

[19:35:54.0000] <heycam>
I see

[19:36:12.0000] <heycam>
well if this is a pattern that we want to go forward with I can certainly add something to the spec

[19:36:28.0000] <TabAtkins>
I guess hold off for now, until we have confirmation that we want to go that way.

[19:36:32.0000] <TabAtkins>
But provisional acceptance is good.

[19:36:55.0000] <heycam>
sure. I don't think it's a bad idea.

[21:48:20.0000] <Hixie>
MikeSmith: was going to ask if you had input on the alt thread on whatwg, from an implementor's perspective, and if you knew what hsivonen's opinion was

[22:16:11.0000] <MikeSmith>
Hixie: haven't caught up on replies on that thread yet

[22:16:15.0000] <MikeSmith>
will read it and see

[22:16:30.0000] <MikeSmith>
I think hsivonen is supportive of adding that attribute

[22:16:53.0000] <MikeSmith>
but we've been having discussions about what the validator behavior for it should be

[22:17:08.0000] <MikeSmith>
e.g., about whether it should cause a once-per-document warning

[22:18:20.0000] <MikeSmith>
Henri has explained why that would not be any better than emitting an error each time, so I'm trying to figure out some other creative way to deal with it

[22:25:33.0000] <MikeSmith>
anybody know who's running the OAuth 2.0 show at IETF?

[22:53:04.0000] <MikeSmith>
so Hixie I read Jukka's message on the alt thread on whatwg and would be happy to reply to any part of that you think I should

[22:53:27.0000] <MikeSmith>
I don't have anything specific to say in reply to it myself at this poitn

[22:53:30.0000] <MikeSmith>
*point

[22:54:57.0000] <MikeSmith>
I think the reply to him from Nils on that one particular question he asked says pretty much what I would have said

[23:08:39.0000] <MikeSmith>
Hixie: replied on the list

[23:08:57.0000] <MikeSmith>
if you want me to say more than what I said in that reply, just let me know

[23:09:32.0000] <MikeSmith>
I expect I can get something implemented in my validator.nu workspace for this over the weekend

[23:58:27.0000] <Hixie>
MikeSmith: awesome, thanks. reply looks perfect.

[23:58:33.0000] <MikeSmith>
¥OK

[23:59:00.0000] <Hixie>
will look more closely next week after doing the response images thread

[23:59:05.0000] <Hixie>
(about 25% through that)

[23:59:08.0000] <Hixie>
nn

[07:07:46.0000] <Velmont>
timeless: Yeah, that's why I said the biggest blocker :P -- But yes, I haven't investigated why it renders wrong, don't know what bug that is.

[07:08:19.0000] <Velmont>
timeless: And it's a "next" (aka unstable) release, so it (not being totally evil) won't autoupdate you to that ;-)


2012-08-05
[01:43:21.0000] <Ms2ger>
    <base href="http://localhost/xhr/resources/">

[01:43:29.0000] <Ms2ger>
/me wonders if anybody passes this test

[02:19:08.0000] <webben>
hsivonen: http://lists.w3.org/Archives/Public/public-html/2012Aug/0098.html - did you mean "because people who evaluate the quality of markup

[02:19:18.0000] <webben>
generators *cannot* be trusted"

[02:19:20.0000] <webben>
?

[02:21:43.0000] <Ms2ger>
That's quite the sentence

[03:32:55.0000] <hsivonen>
webben: oops. right. thanks.

[04:37:10.0000] <hsivonen>
TabAtkins: worse than Gmail saying "you" or "me" is that "me" is mislocalized in Finnish to have the opposite meaning

[04:37:54.0000] <hsivonen>
TabAtkins: (instead of meaning "*by* me", it's localized so that it reads "*to* me")

[04:38:09.0000] <hsivonen>
(well, last I checked. I use Gmail in English to avoid stuff like that)

[05:00:31.0000] <AryehGregor>
It's a different case?

[05:01:22.0000] <AryehGregor>
/me doesn't know a nontrivial amount of any language with nontrivial cases

[05:04:54.0000] <hsivonen>
AryehGregor: yeah, the localization gets the case wrong

[06:27:01.0000] <hoolter>
hey, are <script> elements allowed within <a> ones?

[06:31:26.0000] <AryehGregor>
hoolter, http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-a-element "Transparent, but there must be no interactive content descendant."

[06:31:44.0000] <AryehGregor>
<a> can contain anything its parent can, except interactive content.

[06:31:56.0000] <AryehGregor>
But anyway, yes.

[06:32:06.0000] <AryehGregor>
Anywhere you can use <a>, you can also use <script>.

[06:34:34.0000] <hoolter>
AryehGregor: does that mean no script tags?

[06:35:05.0000] <AryehGregor>
hoolter, that means yes, script tags in <a> are fine.

[06:35:32.0000] <hoolter>
AryehGregor: as long as no visibly represented elements of an interactive nature exist withihn the <a>?

[06:36:22.0000] <AryehGregor>
hoolter, <a> is not allowed to have any descendant elements that are classified as "interactive content".  A full list of those is here:  http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#interactive-content-0

[07:19:40.0000] <nonge>
When lang="zxx" is stated, should one add translate="no", too? Or can/will this be inferred?

[07:54:47.0000] <webben>
nonge: I wouldn't expect it to be inferred; I wouldn't assume it's desirable.

[07:56:34.0000] <nonge>
webben, why wouldn't it be desirable? Afaik "zxx" means that it is no linguistic content; so this *can't* be translated (and it should not … think of an article number like "123-HELLO-456")

[07:57:38.0000] <webben>
oh sorry I thought zxx was just a metasyntactic example

[07:57:54.0000] <nonge>
webben, ah, I see

[07:58:53.0000] <AryehGregor>
nonge, I wouldn't assume browsers know what "zxx" means, no.

[08:02:18.0000] <nonge>
AryehGregor, okay, thanks. So one would have to add both.

[08:02:29.0000] <AryehGregor>
Yeah.

[09:36:30.0000] <zewt>
uhh

[09:36:39.0000] <zewt>
anyone else getting reply spam when posting to whatwg? heh

[09:38:42.0000] <zewt>
http://i.imgur.com/Qa9Xg.png

[10:41:37.0000] <zewt>
also, apparently in gmail it's impossible to mark a single email as spam; only a whole thread

[14:22:38.0000] <Hixie>
zewt: probably an autoreply -- is it always the same person?

[14:24:53.0000] <zewt>
only got it the last time, been a couple weeks since my last post before that

[14:25:14.0000] <Hixie>
k

[14:25:36.0000] <Hixie>
there are people with autoreplies on occasionally -- i post often enough that i get them all the time, but it seems to vary from person to person

[14:25:49.0000] <Hixie>
if there's anyone who is sending autoreplies for more than a day or two then let me know and i'll unsub them

[14:26:11.0000] <zewt>
the only times i see autoreplies on lists tends to be due to a direct CC, rather than a list forward

[14:29:30.0000] <zewt>
(of course, given that it's is a mail host that puts ads for itself with an animated gif logo in posts, it behaving unusually badly isn't exactly surprising)


2012-08-06
[22:43:59.0000] <zewt>
Hixie: i wonder if this amounts to a valid WebVTT use case: http://pastebin.com/pCDhnTWk

[23:19:31.0000] <nessy>
zewt: you'll need to convert to valid tags and timing ;-)

[00:59:47.0000] <Ms2ger>
Why is the view argument to TextDecoder.decode optional?

[03:03:18.0000] <Stevef>
For those zero or more people that frequent this channel intersted in the fate of hgroup in HTML5 I have updated one of my proposals http://www.w3.org/html/wg/wiki/ChangeProposals/hgroup replacement element defined here http://www.html5accessibility.com/tests/subline.html

[07:09:05.0000] <zewt>
Ms2ger: to allow flushing the decoder for stateful encodings, i think

[07:09:27.0000] <zewt>
(without having to construct a dummy ArrayBuffer, which would just be busywork)

[07:15:26.0000] <zewt>
Hixie: btw got another of those mails, same formatting different address, so whatever it is is spoofing senders

[07:18:51.0000] <zewt>
Hixie: haven't squinted at it to see if there's anything useful (headed to work now), but here are both of them, fwiw: http://pastebin.com/CWnKASuT http://pastebin.com/EVDNBS9x

[07:41:55.0000] <smaug____>
hmm, could all the elements which load something have attribute for after-load-event loading

[07:42:10.0000] <smaug____>
could be nice for iframes for example

[07:42:43.0000] <smaug____>
in case of less essential content, like various "like" buttons

[08:03:55.0000] <Velmont>
smaug____: Hehe, like @defer?

[08:04:29.0000] <smaug____>
close to that

[08:05:16.0000] <smaug____>
/me can't remember when 'defer' scripts start loading

[08:05:24.0000] <smaug____>
is it right after DOMContentLoaded

[08:05:33.0000] <gsnedders>
I think so.

[08:05:50.0000] <smaug____>
"the defer attribute is present, then the script is executed when the page has finished parsing"

[08:05:57.0000] <smaug____>
so, I don't want that

[08:06:04.0000] <smaug____>
I want something to happen even later

[08:07:15.0000] <odinho>
Yea, for

[08:07:18.0000] <jgraham>
Well there isn't really anything after "load"

[08:07:30.0000] <jgraham>
Even async scripts are run before that

[08:08:06.0000] <jgraham>
YOu can ofc just run stuff from the load event

[08:08:11.0000] <odinho>
for <img> I'd wanted it to be "whenever, after page has finished loading". etc. So that javascript can choose what to load etc.

[08:09:30.0000] <smaug____>
odinho: well, then you can just have <img>

[08:10:51.0000] <odinho>
smaug____: No, images are prefetched even before script is run.

[08:11:04.0000] <smaug____>
but if you have <img>

[08:11:06.0000] <smaug____>
without src

[08:11:17.0000] <smaug____>
when just set .src using js

[08:11:26.0000] <smaug____>
s/when/then/

[08:11:32.0000] <odinho>
Ah, that won't work in browsers without js/without it turned on.

[08:11:51.0000] <smaug____>
well, you said "So that javascript can choose what to load etc." :)

[08:12:16.0000] <odinho>
smaug____: Well, compat was a prerequisite :P

[08:13:20.0000] <Wilto>
Hixie: Since I know you’re leafing through the respimg threads over the next few days, http://www.w3.org/community/respimg/2012/08/04/picture-in-drupal-8/ and http://www.w3.org/community/respimg/2012/08/04/picture-in-the-html5-spec/ might be worth a read for the current state of Florian Rivoal’s `picture` proposal.

[08:14:13.0000] <smaug____>
hmm, if there was load-after-pageload flag, I wouldn't be surprised if certain kinds of pages would misuse it, and actually load ads etc first, and essential content after pageload

[08:14:23.0000] <smaug____>
that seems to happen with some Finnish news sites

[08:17:10.0000] <Ms2ger>
"A responsive, proportional, nestable, and mobile-first 6-column grid framework."

[08:17:19.0000] <Ms2ger>
Nice buzzword density

[08:18:05.0000] <smaug____>
well, 'A' and 'and' aren't buzzwords :)

[08:22:29.0000] <odinho>
Wilto: You should probably say why you think srcset isn't good enough as specced now. As that was what Hixie wondered last time.

[08:23:04.0000] <tobie>
Hixie: were use cases and requirements for App Cache ever documented somewhere? I've found bits and pieces here and there but nothing concrete.

[08:26:08.0000] <jgraham>
tobie: Generally the "documentation" is mail to the whatwg list

[08:26:59.0000] <tobie>
jgraham: yeah - what I meant by bits and pieces here and there.

[08:29:45.0000] <jgraham>
tobie: I doubt that anyone went through that input and wrote up a summary. Hixie typically doesn't do that in an explicit fashion.

[08:35:02.0000] <tobie>
jgraham: thanks.

[08:45:55.0000] <Hixie>
tobie: the use case was basically "write an app that works whether the user is on a reliable network or not"

[08:46:00.0000] <Hixie>
Wilto: thanks

[08:47:38.0000] <Wilto>
odinho: Yeah, that’s more what http://www.w3.org/community/respimg/2012/06/18/florians-compromise/ is about — I figured everyone was sick of me throwing that link around, by this point.

[08:47:59.0000] <Wilto>
That one was posted to the list not long ago, as well.

[08:50:47.0000] <odinho>
Wilto: But that post does not answer it. :-)

[08:51:26.0000] <tantek>
/me really dislikes framing a solution as a compromise as that implies there is something technical/design about it that has been compromised (deliberately suboptimal).

[08:53:10.0000] <odinho>
Wilto: I'm designing a web site now (magazine), and there is nothing missing in the srcset, as it is currently specced for what I want to do.

[08:53:11.0000] <tobie>
Hixie: that's… broad!

[08:54:14.0000] <Hixie>
tobie: use cases ususally are

[08:54:28.0000] <Hixie>
tobie: at least, use cases for entire sections are :-)

[08:55:05.0000] <Hixie>
if you have a more narrow feature for which you want use cases, let me know :-)

[09:42:54.0000] <Ianrr>
Im trying to use html5lib to parse HTML (python).  I cant find any good examples of how to pull specific tags etc.  Can any point me in the right direction

[09:43:42.0000] <gsnedders>
Ianrr: Depends on what tree-builder you're using.

[09:44:04.0000] <gsnedders>
Ianrr: Basically, it just uses some other library to represent the tree, so you'd have to look at the documentation for that.

[09:44:15.0000] <Ianrr>
etree from lxml

[09:46:04.0000] <gsnedders>
I'd start off looking at the ElementTree documentation, then the lxml documentation.

[09:46:34.0000] <Ianrr>
ahh ok, so how does html5lib fit into this?

[09:46:38.0000] <gsnedders>
In short, you probably want something like doc.find("//{http://www.w3.org/1999/xhtml}p")

[09:46:42.0000] <Ianrr>
it builds the tree?

[09:46:52.0000] <gsnedders>
Ianrr: html5lib just parses the input data into a tree.

[09:47:38.0000] <Ianrr>
so what is the benefit of using say html5lib or just strait up lxml?  html5lib is a more robust parser?

[09:48:21.0000] <gsnedders>
Yeah. libxml's HTML parser won't cope very well with random content on the web, and has a history of infinite loops and other such things.

[09:48:47.0000] <Ianrr>
Ok great.  Thats what I found, it couldn't handle a lot of HTML i threw at it

[10:00:30.0000] <Ianrr>
After I parse out something and then do something like lxml.etree.tostring(some_tag), it prints all the html tags like "</html:ul>"  is there a way to get things to print in normal HTML

[10:00:41.0000] <Ianrr>
Normal HTML meaning no scape before it

[10:00:42.0000] <Ianrr>
scope

[10:00:59.0000] <gsnedders>
Ianrr: lxml.etree.tostring returns XML.

[10:01:07.0000] <Ianrr>
ahh

[10:01:15.0000] <gsnedders>
Ianrr: See html5lib.HTMLSerializer (I think the class is called)

[10:01:36.0000] <Ianrr>
Thank you

[10:01:39.0000] <gsnedders>
Some name along those lines. :P

[10:18:09.0000] <Ianrr>
It seems like etree.tostring() has a method where I can specify xml or html but it still seems to print <html:TAG> for everything

[10:25:02.0000] <Ianrr>
Here is a short sample of what i'm doing and the output http://pastebin.com/RUSQ1FRb

[10:33:17.0000] <Ianrr>
Figured it out, I had to add namespaceHTMLElements=False

[10:33:24.0000] <Ianrr>
to  html5lib.HTMLParser

[11:26:35.0000] <Wilto>
odinho: I mean, it’s a functional markup pattern, for certain. We just have to recognize that unless it continues to be developed and adapted in parallel with media queries, we’d forever be limited to resolution, width, and height as detemining factors, and pixel-based values.

[11:28:23.0000] <Wilto>
Otherwise we have a very specific set of markup that solves a very specific set of use cases. For my part, I use ems in all my media queries; it’s a growing practice amongst developers. In that way, `img srcset` has already already fallen out-of-touch with current practices.

[11:38:24.0000] <tantek>
I recall someone here saying they'd either never heard of people having problems with cloud services (specifically Google's) or themselves had not had any. This is a good article documenting some specific problems, and why "just use the cloud" is an insufficient answer (to anything) http://gizmodo.com/5932161/why-the-cloud-sucks

[11:38:37.0000] <tantek>
(authored by none other than Apple co-founder Steve Wozniak)

[11:39:28.0000] <tantek>
also referenced, Google Calendar, iCloud etc. all the fanboy services.

[12:03:05.0000] <Ianrr>
I want to replace the contents of an HTML <body></body> with a string.  I'm using lxml and etree, any ideas where I would start?

[13:17:14.0000] <jgraham>
Ianrr: body = root[1]; body.clear(); body.text = "your string";

[13:17:20.0000] <jgraham>
Or something like that

[13:24:14.0000] <Ianrr>
thanks i'll give it a try

[13:30:50.0000] <Ianrr>
jgraham:  If I wanted to insert HTML, would I do something like i = etree.tostring(THE_HTML)  then body.insert(i)

[16:08:15.0000] <zewt>
(heh, I've been bit by the confusing namespaceHTMLElements thing myself)


2012-08-07
[21:57:56.0000] <Hixie>
TabAtkins: re our conversation earlier, i went back and an amusingly large number of the things i said you proposed were in fact proposed by others... expected side-effect of me ignoring who's actually writing the e-mails, i guess :-/

[01:29:47.0000] <odinho>
Wilto: I'm not blown away by those arguments. It'd be just as easy to extend srcset if there is any real use cases for it. By doing mediaqueries you're not declarative, but telling it what to do, yea, yea, the worst case is def. taken away in Florian's mix, but it's still there. Looking at the web, I believe most don't need MQ flexibility, but rather something that's short and works in the general case.

[01:32:18.0000] <odinho>
Wilto: And (sorry for repeating) then possibly a more advanced mechanism to do all that super advanced web dev stuff. You could even implement (shim) the meta breakpoint system, or even a substitution system if you could defer the resource load. (and use mediaqueries, or even loading of pictures based on their container (which is not possible with srcset or mediaqueries)).

[04:05:15.0000] <jgraham>
MikeSmith: Any chance of getting the WebPerf testsuite mirrored on github?

[04:05:48.0000] <MikeSmith>
jgraham: sure I'll try to get it set up tomorrow

[04:05:51.0000] <jgraham>
MikeSmith: (eventually I plan to ask this for all web-relevant testsuites on dvcs.w3.org :)

[04:05:59.0000] <jgraham>
MikeSmith: Great, thanks

[08:08:04.0000] <TabAtkins>
Hixie: I'm glad I rank so highly in your mind that you confer all the good suggestions on me, though. ^_^

[08:14:14.0000] <Hixie>
TabAtkins: :-)

[08:16:12.0000] <Hixie>
MikeSmith: it was my understanding that under iana/w3c rules, you didn't have to send registrations to the iana?

[08:16:22.0000] <Hixie>
MikeSmith: at least, not until REC, or something?

[08:16:32.0000] <MikeSmith>
I was asked to send those.

[08:16:37.0000] <Hixie>
by whom?

[08:16:40.0000] <MikeSmith>
plh

[08:16:50.0000] <MikeSmith>
after he talked to IETFers last week I guess

[08:17:12.0000] <Hixie>
is the w3c/iana agreement no longer in force then?

[08:17:17.0000] <MikeSmith>
I actually had an open action item for some time now to do that. I think plh was waiting on the IETF people to get back to him about it.

[08:17:24.0000] <Hixie>
ah

[08:17:26.0000] <MikeSmith>
Hixie: not sure

[08:18:22.0000] <MikeSmith>
I just wanted to clear away an action item. If they don't act on it, I won't mind.

[08:19:25.0000] <Hixie>
oh i guess the process is actually when going to LC, so nevermind

[08:20:20.0000] <Hixie>
speaking of mime types, we really need to get on with the replacement for the iana registry

[08:27:18.0000] <zewt>
grr @ clientHeight/Width being 0 on elements with hidden parents

[08:27:32.0000] <zewt>
whoever decided on that must seriously hate other programmers

[08:27:48.0000] <TabAtkins>
You mean [hidden] parents, right?

[08:28:11.0000] <Ms2ger>
display:none parents

[08:28:16.0000] <TabAtkins>
Yeah.

[08:28:45.0000] <TabAtkins>
Making them non-zero would mean they hate performance, because that would imply they're doing a ton of rendering and layout for things that no one is looking at.

[08:28:56.0000] <TabAtkins>
(And that would, indeed, seriously impact performance on many sites.)

[08:29:12.0000] <TabAtkins>
s/rendering and//

[08:29:51.0000] <zewt>
only if the attributes are examined

[08:30:27.0000] <zewt>
(and if you want to keep them from being accidentally hit, move it to a function)

[08:31:55.0000] <zewt>
i feel like a circus animal at times with the amount of hoop-jumping APIs make me do, heh

[08:48:09.0000] <tobie>
Hixie: Seems like large chunks of the prefer-online specific content (added in http://html5.org/r/7136) is missing from the latest version of the HTML LS spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html). Am I'm not looking at the right document or have there been subsequent edits?

[08:53:50.0000] <Hixie>
that sounds unlikely, let me check

[08:54:09.0000] <Hixie>
do you have an example of what is missing?

[08:54:21.0000] <Hixie>
quick spot-check doesn't find me anything missing

[08:57:45.0000] <Ms2ger>
Hixie, if I have a cross-origin window that contains a frame with name foo, should I be able to access window.foo?

[08:58:33.0000] <Hixie>
beats me

[08:58:39.0000] <Hixie>
what does the spec say and what do UAs do?

[08:59:49.0000] <Ms2ger>
I was hoping to avoid the testing part :)

[09:00:09.0000] <Ms2ger>
The spec says no for window.foo, but yes for window[0], I think

[09:01:06.0000] <Hixie>
it was recently brought to my attention that the spec doesn't match reality for some related aspects of this, so I may have already avoided doing the testing part, unfortunately

[09:01:17.0000] <Hixie>
not sure if it matches in the exact case you mention

[09:01:30.0000] <Hixie>
the thing that was brought up was about navigation, iframes, and window.name, iirc

[09:01:35.0000] <Ms2ger>
Ah, yes

[09:01:41.0000] <Ms2ger>
bz filed that, I think

[09:02:28.0000] <Ms2ger>
This code is horrible in Gecko ::

[09:02:29.0000] <Ms2ger>
:/

[09:02:43.0000] <Hixie>
incidentally, with the forking we're likely to see, it struck me that i should probably start taking a more aware approach to the test suite

[09:03:04.0000] <Hixie>
maybe hosting a copy that matches the whatwg one, since i doubt the w3c's is going to be made to match the whatwg spec when they fork

[09:03:33.0000] <Ms2ger>
That's assuming people who care about the W3C fork write tests :)

[09:03:49.0000] <Hixie>
i would imagine any microsoft-contributed tests will be written to that spec

[09:04:02.0000] <Hixie>
insofar as they are written to any spec, anyway

[09:04:38.0000] <Hixie>
anyway, if anyone has any suggestions, ideas, input, etc, on this front, let me know

[09:05:11.0000] <Hixie>
(i'm happy to let the issue lie until a fork affects the test suite)

[09:05:13.0000] <Ms2ger>
Hmm, MS submitted tests in April, that's more recent than I'd expected

[09:06:23.0000] <Hixie>
tobie: (ping, in case you missed that i replied earlier)

[09:13:07.0000] <tobie>
Hixie, I had, sorry. For example, can't find "candidate" in the spec.

[09:16:37.0000] <tobie>
Hixie: I might be incorrectly assuming all of the said changes are in the offline section only.

[09:17:58.0000] <Hixie>
tobie: oh, i didn't realise you meant specifically only the offline section. Yeah, the changes are all over.

[09:18:11.0000] <tobie>
Hixie: my bad.

[09:18:14.0000] <Hixie>
tobie: navigation algorithm, in particular, has some core stuff

[09:19:47.0000] <tobie>
yeah, makes sense now (and explains why it's hard to pull app cache out of the spec).

[09:20:51.0000] <tobie>
Hixie: the svn repo's private, right?

[09:21:01.0000] <Hixie>
svn.whatwg.org/web-apps

[09:21:03.0000] <Hixie>
public read

[09:21:19.0000] <Hixie>
yeah, pulling appcache out would be seriously painful

[09:21:25.0000] <Hixie>
it's deeply integrated with history and navigation

[09:21:31.0000] <Hixie>
it'd be like pulling out frames or something :-)

[09:21:57.0000] <Ms2ger>
We could pull out history and navigation as well ;)

[09:22:46.0000] <tobie>
Hixie: beautiful, thanks.

[09:23:13.0000] <Hixie>
tobie: if you want blame files, they take forever to generate, but i have a bunch of them cached

[09:23:21.0000] <Hixie>
tobie: so let me know if that's what you're looking for

[09:26:06.0000] <tobie>
Hixie: won't need them now, but good to know those exist.

[09:27:03.0000] <Hixie>
whenever you want them, let me know and i'll give you the urls

[09:27:11.0000] <Hixie>
(i add more to the list as i need them)

[09:39:44.0000] <tobie>
Hixie: if those are online, then sure, the urls would be helpful.

[09:41:25.0000] <jgraham>
Hixie: Yeah, I am quite bothered about the testing thing

[09:41:53.0000] <jgraham>
It seems like one of the few downsides of the split :(

[09:43:43.0000] <Hixie>
tobie: http://www.whatwg.org/specs/web-apps/current-work/blame.rXXXX for the following values of XXXX: 0005 0050 0500 0954 1000 1838 1863 1936 1976 1980 2000 2200 2216 2500 2800 2905 2947 3000 3075 4000 4667 5000 5287 5372 5600 6000 6400 6666 7000

[09:44:13.0000] <Hixie>
jgraham: what's the current state of testing?

[09:44:55.0000] <tobie>
Hixie: Thanks

[09:45:49.0000] <jgraham>
Hixie: In what sense?

[09:46:00.0000] <jgraham>
There are some mercurial repos

[09:46:17.0000] <jgraham>
Various people have contributed tests including MS

[09:46:43.0000] <jgraham>
For HTML, the testing TF is chaired by Kris from MS

[09:47:10.0000] <jgraham>
Obviously the testsuites aren't great yet, but they're not trivial either

[09:47:11.0000] <Ms2ger>
Which means he mostly talks to himself for an hour on IRC every two weeks

[09:47:49.0000] <zewt>
jgraham: are there any requirements on test licensing to make sure the tests can be reused? (eg. by whatwg)

[09:48:20.0000] <Hixie>
jgraham: how plausible is it for us to host a branch/fork/diff somewhere so that we can not duplicate the whole thing but just have a way to track the tests that are wrong?

[09:50:23.0000] <jgraham>
Hixie: In theory that should work

[09:50:34.0000] <Hixie>
but in practice?

[09:50:48.0000] <jgraham>
Hixie: Dunno, I haven't tried :)

[09:51:03.0000] <Hixie>
ah, right

[09:51:20.0000] <jgraham>
Although our plan is to do something similar for hosting the tests inside Opera

[09:51:27.0000] <Hixie>
jgraham: anyone tried writing tests for the stuff we've fixed in whatwg but not htmlwg yet?

[09:51:38.0000] <jgraham>
Hixie: Not as far as I know

[09:52:29.0000] <jgraham>
There have been some small problems due to W3C specs being split and missing X-refs needed to make definitions clear

[09:52:32.0000] <Hixie>
is there a plan for testing features only specced on the whatwg side, like srcset=""?

[09:52:45.0000] <smaug____>
conf calls can be hard "...fell asleep while waiting for the call in front of my computer"

[09:52:56.0000] <Ms2ger>
Just check them in, and see if anybody whines? :)

[09:53:07.0000] <jgraham>
My plan would be to submit tests and see what happens

[09:53:09.0000] <Hixie>
well, yeah, that's kinda where i was heading with this

[09:53:13.0000] <jgraham>
Ms2ger: Exactly

[09:53:30.0000] <jgraham>
I kind of expect MS to object

[09:53:36.0000] <jgraham>
and no one else to care

[09:53:58.0000] <Hixie>
i'd be interested in seeing what would happen

[09:54:04.0000] <Hixie>
there's plenty of things to pick from now: 0005 0050 0500 0954 1000 1838 1863 1936 1976 1980 2000 2200 2216 2500 2800 2905 2947 3000 3075 4000 4667 5000 5287 5372 5600 6000 6400 6666 7000

[09:54:08.0000] <Hixie>
er

[09:54:10.0000] <Hixie>
mispaste

[09:54:14.0000] <Hixie>
there's plenty of things to pick from now: http://www.whatwg.org/specs/web-apps/current-work/#how-do-the-whatwg-and-w3c-specifications-differ?

[09:54:31.0000] <Hixie>
the first bullet has a link to all the changes since the htmlwg side froze

[09:54:53.0000] <Hixie>
and the list at the bottom has some features that are entirely missing on the htmlwg side

[09:55:27.0000] <Hixie>
anyway, sounds like the situation is that it's not yet a situation. keep me posted, because if there's anything i can do to support this i'm more than happy to do so.

[09:55:33.0000] <Hixie>
e.g. if you need servers or whatnot.

[09:56:27.0000] <Ms2ger>
Dammit, you linked me to single-page :)

[09:56:41.0000] <Hixie>
i only use the single-page :-P

[09:56:46.0000] <Hixie>
multipage takes too long to load

[09:56:48.0000] <Hixie>
:-P

[09:57:00.0000] <Hixie>
(single-page just has to be loaded once and left loaded)

[09:57:18.0000] <Ms2ger>
The data element?

[09:57:28.0000] <Ms2ger>
/me never even heard of it

[09:57:29.0000] <Hixie>
what about it?

[09:57:32.0000] <Hixie>
oh

[09:57:37.0000] <Hixie>
replaced the old <time>

[09:57:46.0000] <Hixie>
(a new <time> was later introduced to complement <data>)

[09:57:57.0000] <Ms2ger>
Oh

[09:59:16.0000] <garciawebdev>
good morning

[09:59:18.0000] <garciawebdev>
can the Origin request header be changed?

[09:59:24.0000] <garciawebdev>
from JS?

[09:59:37.0000] <Hixie>
short answer, no

[09:59:41.0000] <zewt>
that would seem to defeat its purpose

[09:59:54.0000] <Hixie>
long answer, which header, exactly? (and then still, no)

[10:00:12.0000] <Hixie>
(what are you trying to do?)

[10:01:05.0000] <garciawebdev>
I need to make a HTTP request to a site, get the HTML page and do stuff with that HTML code (parse it looking for images)

[10:01:34.0000] <Hixie>
ah, yeah, that's pretty much exactly what we're trying to prevent :-)

[10:01:44.0000] <garciawebdev>
I see

[10:01:45.0000] <Hixie>
(so that a hostile site can't "do stuff" to your bank details, e.g.)

[10:02:06.0000] <Hixie>
if you don't have to do it from a web page, though, you can just write a script

[10:02:06.0000] <garciawebdev>
I see

[10:02:09.0000] <Hixie>
then the origin dosn't matter

[10:02:24.0000] <Hixie>
also, if you control the other site, you can have it implement CORS and side-step the issue

[10:02:36.0000] <garciawebdev>
yes, I think I'll end doing it on the server-side

[10:02:55.0000] <garciawebdev>
(no, I don't control the server side)

[10:03:12.0000] <garciawebdev>
it's something almost identical to Pinterest

[10:03:40.0000] <garciawebdev>
(yeah, don't ask why, "client demands")

[10:04:05.0000] <garciawebdev>
so you enter the URL and it looks for pinnable images

[10:04:13.0000] <garciawebdev>
for any site you enter

[10:05:15.0000] <garciawebdev>
so I don't control the URL entered by the user to enable CORS

[10:05:30.0000] <garciawebdev>
but will go with making a server side request

[10:08:23.0000] <garciawebdev>
thanks Hixie

[10:10:28.0000] <gsnedders>
garciawebdev: The other option would be making browser extension, and then syncing it up to server.

[10:14:06.0000] <garciawebdev>
gsnedders: how is that?

[10:28:54.0000] <zewt>
gsnedders: browser extensions are ... usually not really an option for public sites, heh

[10:32:03.0000] <MikeSmith>
Hixie: Coming up with a replacement for the IANA mime-types registry amounts to providing for all the already-registered crazy-ass mime types out there that most people don't care about in practice

[10:32:38.0000] <MikeSmith>
and also for the whole misguided text type vs application type artificial division

[10:32:43.0000] <Hixie>
depends what hte goal is

[10:33:03.0000] <MikeSmith>
well, we should just get rid of the application types completely, for starters

[10:33:16.0000] <Hixie>
if the goal is to replicate the iana registry, then it's probably pointless to bother, they already exist

[10:33:35.0000] <Hixie>
but maybe the goal should just be to document what exists, in less detail than the IANA does for each type, but for more types

[10:33:38.0000] <MikeSmith>
yeah

[10:33:48.0000] <Hixie>
or maybe the goal should be to make MIME types irrelevant

[10:33:53.0000] <Hixie>
or... i dunno

[10:33:54.0000] <MikeSmith>
I don't want to re-do all that vnd.* madness

[10:34:23.0000] <Hixie>
certainly one could imagine making a simpler wiki-style registration mechanism first-come-first-served

[10:34:34.0000] <Hixie>
that doesn't require a Real Spec, just a brief description

[10:34:40.0000] <MikeSmith>
well, restricting it to mime types that are actually relevant to the Web would be a good start

[10:34:44.0000] <Hixie>
and that encourages text/* for text formats, e.g.

[10:34:51.0000] <MikeSmith>
yeah

[10:34:59.0000] <gsnedders>
zewt: No, but depends on what is wanted.

[10:35:12.0000] <Hixie>
anyway, i haven't looked into it, so i'm not really sure what the goal should be

[10:35:23.0000] <Hixie>
the current system is clearly broken, but maybe it's the least broken it could be

[10:35:30.0000] <Hixie>
and maybe it's far more broken than necessary

[10:35:35.0000] <Hixie>
i haven't investigated enough to say

[10:37:36.0000] <MikeSmith>
something that doesn't require dealing with IETF/IANA process would certainly be a plus

[10:38:18.0000] <MikeSmith>
coming to realize more and more that there's a cultural difference there which is very hard to bridge

[10:39:27.0000] <MikeSmith>
e.g., a standards culture that doesn't mandate test cases and implementation reports before a making something a standard

[10:39:40.0000] <MikeSmith>
or doesn't in fact even encourage it

[10:39:57.0000] <Ms2ger>
The W3C?

[10:39:58.0000] <Ms2ger>
Oh

[10:41:03.0000] <MikeSmith>
Ms2ger: you should be assigned to only deal with IETF work for 3 months

[10:41:15.0000] <Ms2ger>
Do you want me dead? ;)

[10:41:25.0000] <gsnedders>
Well, you are nobody. You are Ms2ger.

[10:41:33.0000] <MikeSmith>
have dudes carefully explaining to you why Unicode is bad idea

[10:41:53.0000] <MikeSmith>
where cranks are the norm

[10:41:55.0000] <Ms2ger>
I wonder if they would like pseudonymous people more than the W3C

[10:42:51.0000] <MikeSmith>
instead of "Leading the Web to its full potential", the motto is "Wingnuts fully welcome!"

[10:45:02.0000] <Ms2ger>
Maybe I should try that when the W3C kicks me out

[10:46:05.0000] <MikeSmith>
Ms2ger: there's the guy at IETF who pioneered standards pseudonimity, "m" somebody

[10:46:36.0000] <TabAtkins>
Yeah, after the "m" there were some other character, like "ger", and maybe a number.

[10:47:54.0000] <MikeSmith>
that IETF dude the IETF old guard we're OK with, because inside their club, they all knew who he was, even if all the rest of us didn't

[10:48:54.0000] <Hixie>
i was honestly shocked when websockets when to ietf and i got to experience ietf first-hand

[10:49:22.0000] <Hixie>
i had no idea there could be a group worse than w3c in terms of things like bureaucracy, mis-prioritising, etc

[10:49:24.0000] <zewt>
the only IETF spec i've implemented myself was XMPP, and that made me never want to touch an ietf spec again

[10:49:44.0000] <MikeSmith>
but then they turn around and be the first ones to complain about Ms2ger. Because he's not part of their club

[10:49:48.0000] <zewt>
it basically seemed like a big maze of "shoulds" and "mays" and very little behavior that you could ever depend on

[10:49:51.0000] <Ms2ger>
Hixie, #firstworldproblems

[10:50:07.0000] <Ms2ger>
MikeSmith, oh? They complained?

[10:50:34.0000] <MikeSmith>
zewt: you will enjoy reading the OAuth 2.0 spec. Even the people who wrote it don't know what it says.

[10:51:08.0000] <Ms2ger>
The OAuth guy's blog post was interesting

[10:51:19.0000] <MikeSmith>
Ms2ger: yeah some people complained that since you don't have a Facebook account they can't trust you

[10:51:25.0000] <Ms2ger>
Heh

[10:51:29.0000] <Ms2ger>
I have two

[10:51:30.0000] <Hixie>
Ms2ger: indeed. though on an unrelated note, my dislike of things like telecons and f2fs is largely driven by teh way that they exclude the third world, fwiw. :-)

[10:51:47.0000] <Hixie>
MikeSmith: is THAT why they don't trust me? :-P

[10:51:50.0000] <zewt>
(also implemented the stringprep profile and some SASL bits, which were at little less "shouldy" but still painful)

[10:51:59.0000] <MikeSmith>
Hixie: heh

[10:52:05.0000] <Ms2ger>
A fun question for you all

[10:52:15.0000] <Ms2ger>
<iframe name=constructor></iframe>

[10:52:23.0000] <zewt>
MikeSmith: to state the obvious, I don't think I can trust anyone who bases trust on Facebook :)

[10:52:26.0000] <Ms2ger>
What is window.constructor?

[10:52:47.0000] <Hixie>
Ms2ger: the spec has an answer, dunno if it's the right one :-)

[10:53:39.0000] <zewt>
Hixie: i always cringe when I see people suggesting telecons (as someone did recently on webvtt); it's a pretty good way of making outside contributors like me feel distinctly outside

[10:54:15.0000] <Hixie>
if it makes you feel better, it makes me feel outside too

[10:54:22.0000] <Hixie>
and i'm the editor...

[10:54:53.0000] <Ms2ger>
Making the editor feel outside appears to be standard practice at the IETF

[10:55:37.0000] <Hixie>
man, we're all quite grumpy today :-P

[10:55:48.0000] <MikeSmith>
Ms2ger: of course man

[10:55:50.0000] <TabAtkins>
If it makes you feel better, I'm quite cheeful.

[10:56:04.0000] <Ms2ger>
Because you only need to deal with the CSSWG?

[10:56:13.0000] <Ms2ger>
Wouldn't make me cheerful :)

[10:56:13.0000] <MikeSmith>
the reactionary hive mind is always what's more important

[10:56:26.0000] <MikeSmith>
TabAtkins: rename some more flexbox properties man

[10:56:48.0000] <TabAtkins>
MikeSmith: Nah, I'm past that. I'm going to rewrite gradient syntax instead.

[10:57:05.0000] <MikeSmith>
in other news, this dude has all the answers: https://twitter.com/zackurben/status/232878092295745536 "@w3c needs to compile security guidelines for webdev to follow, so less flaws are available to expose people like @mat http://goo.gl/PBGNF "

[10:57:16.0000] <MikeSmith>
poor @mat

[10:57:17.0000] <Hixie>
o_O

[10:57:29.0000] <Hixie>
yeah mike

[10:57:37.0000] <Hixie>
why aren't you compiling security guidelines

[10:57:59.0000] <Ms2ger>
Clearly the UN needs to take over the internet and require everyone to follow those guidelines

[10:58:20.0000] <MikeSmith>
I will stop everything I'm doing on get started right away on finding ways to save @mat from his own stupidity

[10:58:34.0000] <Hixie>
what did this @mat person do

[10:58:46.0000] <MikeSmith>
got hacked

[10:58:47.0000] <jgraham>
Actually we had some interesting internal feedback on CSP

[10:59:10.0000] <Hixie>
(the funniest part of that quote above btw is the implication that "webdev" read anything we write)

[10:59:36.0000] <MikeSmith>
jgraham: yeah? like what?

[10:59:39.0000] <jgraham>
Basically it turned out that - apart from all the problems with the spec not being interoparbly implemeted - there was a huge problem caused by browser extensions injecting content into the DOM

[10:59:46.0000] <Ms2ger>
Oh, is that the guy with the Apple/Adobe accounts?

[10:59:53.0000] <MikeSmith>
Ms2ger: yeah

[11:00:03.0000] <MikeSmith>
jgraham: no surprise there I guess

[11:00:11.0000] <Hixie>
oh then that quote is even funnier since it wasn't a web vulnerability...

[11:00:23.0000] <zewt>
Hixie: hey, I do :)

[11:00:26.0000] <jgraham>
So the person trying it out basically gave up

[11:00:36.0000] <MikeSmith>
when browsers enable extensions mechanisms that allow extensions to do pretty much anything they want, well...

[11:00:51.0000] <MikeSmith>
it's the same with native mobile apps, really

[11:00:53.0000] <scott_gonzalez>
Hixie: Do you have an rough idea of when you might get around to discussing window.onerror() improvements?

[11:01:10.0000] <jgraham>
MikeSmith: Hard to have an extension mechanism that is both useful and doesn't allow you to add content to web pages

[11:01:42.0000] <MikeSmith>
scott_gonzalez: ?? what specifically? Are the current problems documented somewhere?

[11:01:46.0000] <zewt>
jgraham: well, "simple" javascript interface extensions can be extremely useful by themselves

[11:01:52.0000] <Hixie>
scott_gonzalez: not offhand, are you implementing and blocked on my responding? i can prioritise it if there's an implementor blocked on a decision

[11:02:27.0000] <zewt>
(that is, ones which expose interfaces and maybe fire events but don't touch the DOM directly)

[11:02:35.0000] <MikeSmith>
jgraham: yeah. Same with native apps. People install mobile apps with very little awareness or concern about what they might be doing.

[11:03:04.0000] <scott_gonzalez>
Hixie: I'm not an implementor, I'm a project lead for jQuery.

[11:03:16.0000] <MikeSmith>
Hixie: what's wrong with current window.onerror() ?

[11:03:23.0000] <scott_gonzalez>
MikeSmith: There's a few months old thread, let me find it.

[11:03:25.0000] <Hixie>
MikeSmith: people want a stack trace

[11:03:30.0000] <MikeSmith>
ah

[11:03:32.0000] <Hixie>
if it's the feedback i think it is

[11:03:38.0000] <MikeSmith>
yeah me too

[11:03:40.0000] <MikeSmith>
actually

[11:03:43.0000] <scott_gonzalez>
Hixie: Yes, that's correct.

[11:03:53.0000] <MikeSmith>
well, let's do that

[11:04:02.0000] <MikeSmith>
Hixie: make it happen

[11:04:07.0000] <Hixie>
it has some security implications (we'd have to hide frames from other origins)

[11:04:18.0000] <Ms2ger>
tc39 is speccing some sort of Error.stack, IIRC

[11:04:29.0000] <Hixie>
Ms2ger: there's not always an Error

[11:04:38.0000] <scott_gonzalez>
Yes, TC39 strawman: http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

[11:05:41.0000] <Hixie>
anyway, if it's not blocking an implementor then it'll just be addressed in the normal course of things -- i go through feedback in a first-come-first-served basis.

[11:06:35.0000] <scott_gonzalez>
There's a six year old bug filed against Mozilla, but I don't believe it's on anyone's radar right now: https://bugzilla.mozilla.org/show_bug.cgi?id=355430

[11:06:57.0000] <scott_gonzalez>
Perhaps I can bug some Mozilla devs to make it high priority :-)

[11:07:18.0000] <Ms2ger>
Good luck with that, they need to get a phone shipped

[11:07:20.0000] <scott_gonzalez>
Though it seems to make sense to have TC39 standardize Error.stack first.

[11:08:01.0000] <Hixie>
currently the feedback on this topic is from May, and the oldest feedback i have to deal with is from 2009.

[11:08:19.0000] <Hixie>
though if we ignore feedback that i'm likely to continue not addressing before i get to this onerror thing, the oldest feedback is from january

[11:08:33.0000] <Hixie>
so about 4 months behind the onerror thing

[11:08:44.0000] <Hixie>
so not too bad

[11:09:27.0000] <scott_gonzalez>
Do you have an approximate burn rate on the backlog?

[11:10:10.0000] <scott_gonzalez>
I'm not looking for anything concrete at all, "weeks" or "months" is good enough. Just looking for something to bring back to the rest of the team.

[11:10:26.0000] <Hixie>
months

[11:10:47.0000] <scott_gonzalez>
ok

[11:11:10.0000] <Hixie>
i'm never closer than about one month lag, because it takes about a month for threads to settle. i'm currently averaging about 6 months lag (with some outliers, as i mentioned above), but generally i'm a bit better than 6 months, maybe 3 or so.

[11:11:28.0000] <Hixie>
my main current task is to make this better, fwiw :-)

[11:11:44.0000] <Hixie>
(leaving w3c being a huge part of that)

[11:12:59.0000] <Hixie>
(if i respond to threads before they settle, i.e. less than 1 month lag, it ends up causing more hassle than it's worth becuase people haven't yet sent their feedback and hte spec churns more)

[11:13:21.0000] <Hixie>
hey, it's mr jennings!

[11:15:20.0000] <cullenjennings>
drop in now and then for a breath of fresh air from the usual cesspools I hand out in :-)

[11:15:50.0000] <Hixie>
this is pretty cesspooly too :-P

[11:15:52.0000] <scott_gonzalez>
Ok, we'll continue to work on error.stack in TC39. Hopefully we can get that finalized by the time WHATWG gets to window.onerror.

[11:16:15.0000] <Hixie>
scott_gonzalez: that would certainly help, if there's prior art then i generally try to just use it, makes my life way easier

[11:16:27.0000] <Hixie>
scott_gonzalez: (if there's some way i can hook into it, that'd be awesome)

[11:16:47.0000] <Hixie>
scott_gonzalez: (e.g. keeping it non-exception-specific)

[11:17:23.0000] <scott_gonzalez>
You'll need something for compile errors which don't have Error objects, correct?

[11:18:01.0000] <Hixie>
well compile errors probabyl don't have stacks

[11:18:44.0000] <Hixie>
though come to think of it, maybe only exceptions will ever have stacks, in onerror

[11:18:56.0000] <Hixie>
in which case it's fine, i just need a way to get the stack out of the unhandled exception object

[11:18:59.0000] <Hixie>
or just expose that object

[11:19:04.0000] <Hixie>
which would imho be even more ideal

[11:36:13.0000] <MikeSmith>
btw http://platform.html5.org/specs/

[11:36:56.0000] <Ms2ger>
Ooh, it looks different

[11:37:30.0000] <Hixie>
it's artificially inflated by listing all the HTML sections as separate specs :-)

[11:37:35.0000] <Hixie>
(e.g. workers and storage)

[11:38:05.0000] <Ms2ger>
Otherwise it's artificially inflated by you sticking everything in one spec ;)

[11:55:30.0000] <zewt>
anyone recall offhand where the @microsoft response was re "we'll never change encoding behavior in any way, period", can't recall if it was on @webapps or the tracker or what

[11:57:25.0000] <zewt>
(at least I know I don't have to search @whatwg ... heh)

[11:58:34.0000] <Ms2ger>
IETF somewhere, I think

[11:58:44.0000] <zewt>
maybe there too, I'm not on any ietf lists

[12:00:21.0000] <Ms2ger>
I'd look, but http://mail.apps.ietf.org seems down

[12:01:29.0000] <zewt>
can I shoot the w3 bug tracker into the sun, between blocking search engines and not including email addresses on comments

[12:01:57.0000] <zewt>
2012 and I can't do a simple "site:w3.org/Bugs microsoft.com" search

[12:03:14.0000] <Hixie>
if you log in it includes e-mail addresses

[12:05:52.0000] <Ms2ger>
http://comments.gmane.org/gmane.ietf.charsets/578

[12:05:59.0000] <Ms2ger>
zewt, ^

[12:07:16.0000] <zewt>
what an amusingly terrible email archive viewer, heh :P

[12:07:44.0000] <Ms2ger>
It's slightly better than "Unable to connect" :)

[12:08:25.0000] <zewt>
(it's the "Continue reading" thing that makes it seem terrible to me, incidentally)

[12:08:58.0000] <Ms2ger>
Oh, I hadn't even seen that

[12:09:53.0000] <zewt>
I missed it on the first couple mails, until one came up that was more obviously truncated

[12:10:36.0000] <Hixie>
TabAtkins: ok, i sent my reply, you can send your srcset feedback without making my life hard :-P

[12:11:13.0000] <zewt>
Ms2ger: the latter part of that mail (http://permalink.gmane.org/gmane.ietf.charsets/588) makes me lose another little chunk of hope for IE

[12:11:30.0000] <zewt>
"use unicode", as if the existing web with millions of non-unicode pages somehow doesn't exist

[12:12:18.0000] <Ms2ger>
It's not clear to me that guy works on IE

[12:13:30.0000] <Hixie>
i send a reply and a checkin. i get three autoreplies, one spec update automated e-mail, an e-mail from evernote telling me someone's inbox is full, and some unrelated spam.

[12:13:50.0000] <Hixie>
oh and two mailman bounce notifications

[12:14:19.0000] <Hixie>
bbl. lunch.

[12:14:22.0000] <Ms2ger>
No wonder you've got a lot of unread email

[12:17:10.0000] <TabAtkins>
Hixie: Do you end up bccing everyone who you crafted your megaemails from?

[12:17:21.0000] <TabAtkins>
I'm trying to figure out why your megaemails don't get the whatwg label.

[12:19:45.0000] <zewt>
TabAtkins: i'm not even sure what the list() gmail filter/search criteria matches against

[12:19:57.0000] <TabAtkins>
I have no clue.

[12:20:27.0000] <Ms2ger>
I assume the List-Id: Public mailing list for the WHAT working group <whatwg-whatwg.org>

[12:21:53.0000] <zewt>
gmail fail: the "show original" dropdown menu item isn't a functional link, so I can't middle-click it into another window

[12:22:09.0000] <zewt>
yearning for the days when google pages were actually a good model for others to follow

[12:22:59.0000] <zewt>
TabAtkins: i also don't know how gmail combines duplicates when you're copied on a list you're on; normally it seems to figure it out and prefer the list copy, I think, but that didn't seem to happen here

[12:23:16.0000] <zewt>
maybe because I opened the mail before receiving the list version, or something

[12:23:31.0000] <TabAtkins>
Possibly, I guess.  My experience with its deduping is pretty good.

[12:23:31.0000] <zewt>
(presumably this 250 gigabyte email takes longer to be distributed than most)

[12:23:48.0000] <Wilto>
Hixie: Are you still winding your way through the respimg threads?

[12:24:01.0000] <zewt>
"mucking" might be an appropriate verb

[12:25:24.0000] <Wilto>
You ain’t wrong, zewt.

[12:26:35.0000] <Wilto>
That’s why I’m checking in first; don’t wanna throw anything else on the pile if he’s still working through it.

[12:27:23.0000] <zewt>
quotostrophes!

[12:28:21.0000] <zewt>
Wilto: i just gave up on that; the S/N was worse on that thread than anything I've seen on the list since I subscribed

[12:28:29.0000] <zewt>
by a staggering margin

[12:29:13.0000] <Wilto>
Yeah, I don’t disagree. Trust me, the subject seems to invite a great deal of “just thinking out loud here” posts and comments and whatnot.

[12:30:09.0000] <Wilto>
If I get one more “why don’t we just use javascript” post in the Community Group, I’m moving to an internet-free island somewhere.

[12:30:36.0000] <TabAtkins>
/me prepares a new email missive.

[12:30:53.0000] <Wilto>
I am afraid to ask.

[12:31:15.0000] <TabAtkins>
Hey, it only takes one more email to move you to an island.  I'll just nudge you. ^_^

[12:31:28.0000] <Wilto>
I get that a lot.

[12:32:16.0000] <zewt>
the whole thing had the feel of a petition

[12:32:45.0000] <zewt>
"let's get all of our friends to join up and make some noise! show our rage!"

[12:32:54.0000] <Wilto>
Yeah. Honestly, I take the blame for that.

[12:33:30.0000] <Wilto>
I forget who it was, but being asked to furnish “proof” of developer sentiment between the two pattens set me off.

[12:34:13.0000] <Hixie>
TabAtkins: yes, i usually bcc anyone who wrote the mail, in case they've since unsubscribed

[12:34:26.0000] <Hixie>
TabAtkins: (and gmail randomly picks one to dedupe)

[12:34:44.0000] <zewt>
has "developer sentiment" ever trumped technical arguments or use cases? heh

[12:34:45.0000] <TabAtkins>
Okay.  I'll amend my filter to catch these.

[12:35:05.0000] <Wilto>
zewt: Nope, just one piece of a very large puzzle.

[12:35:21.0000] <zewt>
am I weird for writing css rules like "#foo #bar" where #foo is basically a comment

[12:35:21.0000] <Hixie>
Wilto: just sent a reply to the last 340 e-mails on that thread in the whatwg

[12:35:24.0000] <zewt>
heh

[12:35:54.0000] <Hixie>
Wilto: (fixed a few bugs, but didn't make any big changes to the design, because there were no new use cases to justify a new design)

[12:35:57.0000] <Wilto>
Hixie: I’m re-reading now, but I didn’t see anything on the compromise pattern currently being worked on with the HTML WG.

[12:36:30.0000] <zewt>
(when in the English language history did "compromise" become a positive word?)

[12:36:40.0000] <Wilto>
…You’re saying you didn’t catch anything about values other than pixels?

[12:36:44.0000] <Hixie>
Wilto: no idea what's happening in the html wg. there were many proposals, i tried to respond to all the ones that introduced something new.

[12:36:46.0000] <zewt>
"compromise your principles" and "a security compromise" became "you have to compromise!"

[12:37:22.0000] <Hixie>
Wilto: there were some discussions about non-pixel things but they weren't anything new. i did respond to those though.

[12:37:29.0000] <Hixie>
zewt: yeah, i actually mentioned that in my e-mail just now :-)

[12:37:32.0000] <Wilto>
I don’t use pixel-based media queries, and more and more developers are adopting em-based media queries to account for user zooming. Will `srcset` be expanded to include ems as well?

[12:37:46.0000] <Wilto>
Oh, here we are—sorry. Reading.

[12:37:59.0000] <Hixie>
zooming also zooms px

[12:38:28.0000] <Wilto>
…Pixel-based media queries are not reevaulated on page zoom.

[12:38:42.0000] <Wilto>
Em-based media queries are, according to the recalculated root font size.

[12:38:52.0000] <Wilto>
16px by default, but changes with zoom.

[12:39:07.0000] <Wilto>
As such, the layout will be reevaluates as the user zooms in and out.

[12:39:09.0000] <Hixie>
you are either wrong, or confusing page zoom with default text size

[12:39:24.0000] <Hixie>
the only thing 'em' does that 'px' doesn't is for the very few users who have a 'medium' font-size set to something other than 16px, which imho is going to dwindle to zero over time.

[12:39:29.0000] <Wilto>
http://blog.cloudfour.com/

[12:39:44.0000] <Wilto>
Zoom in on that multiple times. You’re in Chrome I assume, so you’ll need to refresh for the layout to change.

[12:39:45.0000] <Hixie>
anyway, i have to run to lunch -- if there's new information, send it to the list :-)

[12:39:54.0000] <Hixie>
(but please read the e-mail i sent first!)

[12:39:57.0000] <Wilto>
—you’re kidding me.

[12:39:59.0000] <Hixie>
bbl

[12:41:15.0000] <zewt>
(i have a non-default font size in Chrome, since it makes pages easier to read without making every image on every page get non-power-of-2 scaled, eg. blurry)

[12:41:54.0000] <zewt>
(i'll grant that as a web author, i hate people like me)

[12:42:06.0000] <Wilto>
Yeah. With em-based media queries, the layout would change accordingly. Check out that CloudFour link; it reevaluates immediately in Opera and Firefox, but requires a reload in Chrome. Canary I think reevaluated immediately.

[12:42:14.0000] <Wilto>
All the benefits of zooming, without the broken layout.

[12:43:44.0000] <Wilto>
It’s brilliant, and crazy easy to implement.

[12:43:53.0000] <Wilto>
To author, rather.

[12:45:56.0000] <Wilto>
When using ems to determine source images, we could ensure that the images remain layout-appropriate.

[12:46:19.0000] <Wilto>
Or at the very least, less-blurry.

[12:52:03.0000] <Wilto>
I might recommend those involved in the discussion read http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw for a better sense of how ems behave in media queries.

[12:52:36.0000] <jgraham>
Wilto: It might be more convincing if you could point to spec text rather than blog entries

[12:52:42.0000] <Wilto>
Or author some.

[12:53:25.0000] <Wilto>
http://www.w3.org/TR/css3-mediaqueries/#units

[12:53:43.0000] <zewt>
there's no querySelector() for matching up the ancestor list rather than down? :|

[12:54:01.0000] <Wilto>
In modern browsers, initial font-size is increased or decreased — at varying increments, depending on the browser — with zoom.

[12:54:40.0000] <Wilto>
jgraham: And with all due respect, I’m not presenting an argument. This is how em-based media queries work, full stop.

[12:54:55.0000] <Wilto>
I invite anyone involved to prove me wrong.

[12:55:02.0000] <jgraham>
Wilto: I'm not suggesting that it is an argument

[12:55:11.0000] <Wilto>
Let me rephrase, then.

[12:55:22.0000] <jgraham>
I'm suggesting the right citation for behaviour is spec text

[12:55:26.0000] <Wilto>
I’m not trying to be “convincing.”

[12:55:27.0000] <jgraham>
Not blog posts

[12:55:52.0000] <Wilto>
I cited a live example, at first.

[12:55:55.0000] <jgraham>
(unless you are claiming that browsers violate the spec, in which case the correct citation is test cases)

[12:56:09.0000] <Wilto>
In use on a production website, and supported in every major browser.

[12:56:18.0000] <Ms2ger>
/me yawns

[12:56:43.0000] <zewt>
and no call to ask if an element matches a selector, without traversing children? :|

[12:57:23.0000] <Ms2ger>
.mozMatchesSelector()?

[12:57:49.0000] <zewt>
primary audience is webkit, heh

[12:58:06.0000] <zewt>
(was looking for the latter to implement the former myself, eg. searching up the tree)

[12:58:29.0000] <TabAtkins>
zewt: Yeah, jQuery's .closest() function is *ridiculously* useful.

[12:58:34.0000] <zewt>
(... without having to pull in jQuery or prototype)

[12:58:46.0000] <zewt>
prototype has .up(), iirc (been a while since I've used it)

[12:59:19.0000] <jgraham>
(media queries is a terribly written spec)

[13:00:04.0000] <zewt>
guess there's webkitMatchesSelector too

[13:00:42.0000] <TabAtkins>
Polyfill *MatchesSelector, then do "while(!el.matchesSelector('foo')) { el = el.parentNode; }" for now.

[13:00:54.0000] <zewt>
yeah, started on that already :)

[13:01:23.0000] <zewt>
(well, not sure yet if I'll polyfill it if it's missing entirely; need to check who supports it first)

[13:16:18.0000] <gsnedders>
Lone surrogates are the bane of my existance.

[13:16:43.0000] <zewt>
heh

[13:17:22.0000] <zewt>
at least with utf-8 you have to deal with multibyte data all the time, so there's at least a clear reason to spend time getting it right

[13:18:02.0000] <gsnedders>
The problem is Python nowadays rejects invalid UTF-8 sequences, inc. those with surrogates.

[13:47:21.0000] <zewt>
bleh, wonder if there's any way to have an <img> with no src (since src is in by script later) that doesn't either make the validator whine or cause a dummy fetch+onerror

[13:47:35.0000] <zewt>
(short of creating the img entirely programmatically, which I'd prefer not to do)

[13:51:48.0000] <TabAtkins>
Use a data for an empty png

[13:51:55.0000] <TabAtkins>
data: url, rather.

[13:56:34.0000] <gsnedders>
Is there any character encoding that Python supports that allows lone surrogates?

[13:56:50.0000] <gsnedders>
/me is on tethered 2G connection, so…

[14:15:57.0000] <zewt>
dumping a line of copied-and-pasted gibberish into HTML source seems like an unfortunate thing for validators to encourage, heh

[14:19:54.0000] <zewt>
(not that I'm sure what other browsers do--just that at least WebKit does what I want with no @src, which is nothing)

[14:37:43.0000] <chriseppstein>
So we've just added pixels to the conversion tables in Sass so that users can convert between say px and inches, etc. https://github.com/nex3/sass/commit/1bd914960252ead6876b816d7335696d43ecbd35 and now all my users are asking whether browsers really treat 96px as 1in or whether they are screen pixels and I want to tell them the right answer. can someone here enlighten me?

[14:39:03.0000] <TabAtkins>
Yes, 96px = 1in, forever.

[14:39:23.0000] <TabAtkins>
If you're wondering why, blame everyone who mixes px and pt and expects a constant ratio or else their layouts break.

[14:41:24.0000] <chriseppstein>
TabAtkins: even on devices that actually have pixels? Seriously this is breaking my brain. I didn't believe it until I read it in the spec all the way back to css2

[14:41:48.0000] <Hixie>
chriseppstein: yes

[14:42:45.0000] <chriseppstein>
If I'm on a device with 72pixels per inch, I'm actually going to get 3px on the screen for every 4px in my code?

[14:42:54.0000] <Hixie>
chriseppstein: 1px = 0.264583mm = 0.010416in = 1.333pt

[14:43:19.0000] <TabAtkins>
chriseppstein: Yes, on all devices, everywhere, forever.

[14:43:19.0000] <Hixie>
where px = CSS pixels, mm = CSS millimeters, in = CSS inches, and pt = CSS points

[14:43:34.0000] <Hixie>
and they have nothing to do with real pixels, real millimeters, real inches, or real points

[14:43:46.0000] <chriseppstein>
I love CSS

[14:43:54.0000] <Hixie>
(except that on most displays, 1 CSS pixel maps to 1 device pixel, if the user hasn't zoomed)

[14:43:58.0000] <TabAtkins>
Again, it's to support a lot of legacy content engineered for screens that were (or pretended to be) 96dpi.

[14:44:50.0000] <Hixie>
it's wasn't meant to be this way, but web devs misused the various units, only tested in IE and Netscape on Windows, and we were stuck

[14:44:58.0000] <chriseppstein>
Ah I see. it's because CSS inch isn't actually a ruler inch?

[14:45:02.0000] <Hixie>
right

[14:45:04.0000] <Hixie>
it's 96 pixels

[14:45:08.0000] <chriseppstein>
omg

[14:45:08.0000] <Hixie>
CSS pixels

[14:45:35.0000] <chriseppstein>
Ok. I get it now

[14:45:38.0000] <chriseppstein>
thank you

[14:45:53.0000] <zewt>
(many/most desktop systems have no idea how big the display is to begin with, so it's not even implementable, and you really don't want "inches" most of the time anyway--think projectors)

[14:46:06.0000] <TabAtkins>
The CSS in unit can, in practice, map to anything between 2/3 and 3/2 of a real inch, on a screen at normal length.

[14:46:22.0000] <TabAtkins>
Depending on how close you are to an integer multiple of 96dpi.

[14:46:58.0000] <Hixie>
and that's assuming you're not zooming

[14:47:06.0000] <TabAtkins>
Yeah, at normal zoom.

[14:47:17.0000] <Hixie>
nor on a projector, as zewt says :-)

[14:47:38.0000] <chriseppstein>
You had me at 1in != 1in

[14:47:39.0000] <TabAtkins>
In high-dpi devices like printers, a CSS inch should be very close to a real inch, and a CSS px will be 1/96 of that.

[14:47:53.0000] <Hixie>
1in != 1"

[14:47:58.0000] <chriseppstein>
that

[14:48:04.0000] <TabAtkins>
On monitors, a CSS px is usually mapped to an integer number of device pixels, and then a CSS in is 96 of them.

[14:48:38.0000] <TabAtkins>
(For some reason, there's apparently a lot of random mobile devices which don't map CSS px to an integer number of device pixels.)

[14:49:42.0000] <zewt>
help @ artist giving me a PSD site mockup with embossed text in buttons

[14:50:01.0000] <TabAtkins>
zewt: text-shadow is your friend, if you want to match that.

[14:50:54.0000] <zewt>
trying to match photoshop bevel effects is a headache, heh (but using a baked image would be an even bigger headache, when l10n time comes around)

[14:51:08.0000] <zewt>
(of course I could probably drop it and nobody would noticed, but I'll give it a shot)

[14:51:12.0000] <zewt>
also notice

[14:57:00.0000] <chriseppstein>
TabAtkins: while I'm here, I've been making a patch for calc() support in sass

[14:57:39.0000] <chriseppstein>
can I ignore prefixes at this point and just support the standard? We'd really like to avoid putting browser support concepts into the core language

[14:58:27.0000] <TabAtkins>
Yes.  The spec is CR, so prefixes will drop soonish.

[14:59:12.0000] <chriseppstein>
lovely

[14:59:22.0000] <chriseppstein>
who supports it unprefixed right now?

[15:02:23.0000] <TabAtkins>
dunno!

[15:02:31.0000] <chriseppstein>
i'll look it up. thanks

[16:06:38.0000] <Hixie>
so... http://www.ietf.org/mail-archive/web/ietf-types/current/msg01719.html tell me again why "stability" is a good thing?

[16:07:32.0000] <hober>
Hixie: that email is amazing.

[16:08:25.0000] <zewt>
Hixie: s/stability/ietf/

[16:20:01.0000] <hober>
Hixie: you said earlier that you had replied on the adaptive image thread, but i haven't seen the mail come through. mailman issue?

[16:21:30.0000] <Hixie>
oh, right, probably too big

[16:21:33.0000] <Hixie>
thanks for pointing that out

[16:21:46.0000] <Hixie>
i was wondering why nobody had replied...

[16:22:23.0000] <Hixie>
that's weird, my message is in the queue twice

[16:23:08.0000] <Hixie>
ok should be sent now

[16:23:25.0000] <Hixie>
in other news i was thinking of posting something like this to a list apart and our blog: http://wiki.whatwg.org/wiki/What_you_can_do#How_you_can_improve_HTML

[16:23:35.0000] <Hixie>
if anyone wants to review that, please do let me know if you see any issues

[16:34:07.0000] <zewt>
a siren needs to go off on people's systems whenever they're about to post a /TR/ link to a mailing list, heh

[16:34:24.0000] <Hixie>
haven't had this low number of pending e-mails since 2010, woot


2012-08-08
[17:18:10.0000] <zewt>
wow, cancelling mousedown in chrome is being really strange

[17:18:45.0000] <zewt>
causes a click to be registered if the mouseup happens while the mouse is over the element; no "minimum drag distance" click cancels happen at all

[17:19:01.0000] <zewt>
new one for me

[17:20:31.0000] <tantek>
Thanks hober.

[17:20:36.0000] <tantek>
/me smiles at https://www.w3.org/Bugs/Public/show_bug.cgi?id=18231#c1

[17:22:33.0000] <tantek>
Hixie, the What you can do write-up seems reasonable, given your preferred methods of working/communication.

[17:22:45.0000] <tantek>
The only thing I'd change is to move this sentence to the start: "The best place to start is to join us on IRC and ask what you can do. "

[17:34:32.0000] <zewt>
eh? it's happening in firefox too--even more bizarre

[17:35:46.0000] <zewt>
maybe I've just never implemented something that's both drag-scrollable and clickable before to never have noticed this, but it's nonsensical behavior

[17:55:24.0000] <Hixie>
tantek: heh, i'm amused at the difference in how he handled it vs how i handled it. :-) https://www.w3.org/Bugs/Public/show_bug.cgi?id=17499

[17:56:43.0000] <Hixie>
tantek: i thought about doing that but i think the best place to start for suggesting a new feature is to describe the problem and post it to the list, not join IRC. joining IRC is more for just participating in existing discussions, which is what the last few paragraphs are about

[18:10:16.0000] <tantek>
Hixie, asking about a general problem area on IRC may be faster than spending time writing up a more thorough description (what people tend to do on email) of the problem and posting it on the list.

[18:11:07.0000] <tantek>
and if it's not already known problem area, a bit of back/forth on IRC from the "regulars" may help a new person better frame/describe their problem in a writeup for the list (or wiki), which should increase efficiency for everyone involved.

[18:13:36.0000] <Hixie>
fair enough

[18:14:14.0000] <Hixie>
/me looks at how to phrase it

[18:14:32.0000] <Hixie>
i definitely don't want to encourage people to come to irc before they're thought about what their problem is

[18:14:38.0000] <Hixie>
so it can't be the first step

[18:24:10.0000] <Hixie>
i don't really see how to do it

[18:24:53.0000] <zewt>
Hixie: better than posting to the list before they've thought about it :)

[18:28:53.0000] <Hixie>
zewt: well, the article suggests very strongly that they don't do that, no?

[18:29:39.0000] <zewt>
Hixie: but putting irc above or below the mailing list shouldn't change that very much

[18:30:21.0000] <Hixie>
i just don't see how to phrase it in a way that doesn't hurt the flow

[18:30:28.0000] <zewt>
(and if people are going to come in with half-formed ideas, better it be on IRC than the list, IMO)

[18:30:54.0000] <tantek>
Hixie, something like, Optional: considering pinging briefly on IRC about your general problem area to see if the folks there might suggest a quick solution, or perhaps offer suggestions for how to better phrase/writeup your problem description for the list (or wiki)

[18:31:19.0000] <tantek>
on that zewt, I have to agree.

[18:31:42.0000] <zewt>
(noise on IRC based on an idea that hasn't been formulated well enough is less likely to trigger a two-week ill-formed discussion than on the list)

[18:31:55.0000] <tantek>
= more efficient

[20:07:40.0000] <Hixie>
i shall have to look into it in the morning

[00:14:15.0000] <Smylers>
From Hixie's mammoth src-set mail: “While the page is loading, the user's roommate starts watching an HD show on Hulu while his neighbour, also using the wife, starts downloading a 4GB file on Bittorrent.”

[00:14:46.0000] <Smylers>
I'd've thought that if his neighbour is using his wife, he's got more to worry about than the speed at which his images are downloading ...

[00:14:47.0000] <jgraham>
MikeSmith: Did you have a chance to look at Web Perf -> github yet?

[00:15:05.0000] <jgraham>
Smylers: Different people have different domestic arragements :)

[00:27:09.0000] <MikeSmith>
jgraham: not yet but will do it later today

[00:30:52.0000] <jgraham>
MikeSmith: Thanks :)

[02:18:31.0000] <odinho>
Hixie: [The how to improve HTML article] That bug link is kinda ugly, yes, but still, is it better to place it behind an url shortener?

[02:54:53.0000] <matjas>
odinho, Hixie: perhaps a more descriptive short URL would be better, e.g. http://html5.org/bug

[02:55:49.0000] <odinho>
matjas: Yea, and one that is controlled by the project itself. -- Not that I don't trust Google or anything, it's just ... not good having single point gatekeepers :]

[02:55:50.0000] <matjas>
/me sets up http://mths.be/htmlbug

[02:56:08.0000] <matjas>
(for personal use)

[02:56:11.0000] <matjas>
odinho: exactly

[02:56:51.0000] <odinho>
I even have my own s0.no for short urls when I really needed it. But I stopped using it. Got it when short urls were all the rage back in 2007 or when it was.

[02:58:15.0000] <matjas>
hipster!

[02:58:22.0000] <odinho>
:P

[03:02:45.0000] <jgraham>
odinho: Do you also ride a bike with only one gear?

[03:03:02.0000] <odinho>
jgraham: I looked for one, actually! :D lol

[03:03:27.0000] <odinho>
jgraham: Because it's easier tech, so it might not be too prone to breakage. And easy to fix.

[03:03:32.0000] <odinho>
Oh man.

[03:03:35.0000] <odinho>
/me hides

[07:22:11.0000] <Wilto>
Hixie: I’m happy to pass that post along to the rest of the ALA team, whenever you’d like.

[07:43:04.0000] <tobie>
Hixie: holding a small informal meet up on AppCache woes next week (yeah, I know, it's a pet peeve of mine). What kind of output would be most useful to you, if any?

[07:47:03.0000] <Ms2ger>
w3c: 'XForms 2.0' and 'XForms 2.0: XPath expression module' Drafts Published http://t.co/QnC7c4Mw

[08:35:19.0000] <dglazkov>
good morning, Whatwg!

[08:38:46.0000] <odinho>
good evening! :D

[08:46:22.0000] <garciawebdev>
good morning

[08:46:32.0000] <garciawebdev>
are PUT and DELETE HTTP methods supported by most modern browsers and IE7+ ?

[10:24:23.0000] <hober>
I take it at this point that the Anolis repo at hg.gsnedders.com is not the most recent version that people actually use?

[10:24:51.0000] <Ms2ger>
Nope

[10:24:59.0000] <Ms2ger>
https://bitbucket.org/ms2ger/anolis

[10:25:05.0000] <hober>
word.

[10:26:12.0000] <Ms2ger>
There's some more documentation somewhere on wiki.whatwg.org

[11:10:58.0000] <Ms2ger>
/me waves at Geoffrey Sneddon (New to Bugzilla)

[11:56:35.0000] <gsnedders>
Ms2ger: I'm new to Bugzilla?

[11:56:49.0000] <Ms2ger>
Apparently :)

[11:57:39.0000] <gsnedders>
Interesting, given my account is almost 8 years old. :)

[12:41:17.0000] <Hixie>
odinho, matjas: good point, will change that url

[12:41:44.0000] <Hixie>
Wilto: zeldman gave me an e-mail address to use, so i'm good. but thanks.

[12:41:59.0000] <Hixie>
tobie: use case descriptions that don't mention appcache :-)

[12:48:38.0000] <Hixie>
that wifi/wife typo is really weird -- i and e aren't near each other on any keyboards that i used to type that, and it's not like i type the word "wife", like, ever (certainly not as often as wifi), so i don't see why there'd be muscle memory!

[12:48:42.0000] <Hixie>
funny though

[12:49:15.0000] <Ms2ger>
Freudian slip?

[12:51:41.0000] <Hixie>
that i want to use the neighbour's wife? my neighbour isn't married, as far as i know.

[12:54:53.0000] <Hixie>
tantek: i added an earlier mention of IRC at http://wiki.whatwg.org/wiki/What_you_can_do#How_you_can_improve_HTML -- what do you think?

[13:05:50.0000] <Ms2ger>
Bah

[13:06:09.0000] <Ms2ger>
This microsoft test uses video.startTime

[13:06:15.0000] <Ms2ger>
Which apparently doesn't exist

[13:37:44.0000] <jgraham>
Hixie: It reads like you mentioned IRC twice even though you didn't quite

[13:38:20.0000] <jgraham>
Also, you should probably mention that real-world examples of people working around the lack of a feature are useful

[13:38:50.0000] <jgraham>
i.e. people addressing the use case using existing technologies

[13:58:28.0000] <Yuhong>
http://news.ycombinator.com/item?id=4336924

[13:58:33.0000] <Yuhong>
On the HTML5 buzzword.

[14:07:51.0000] <jarek>
it's not a buzzword, it's a marketing term

[14:09:21.0000] <Yuhong>
And a misleading one at that.

[14:09:54.0000] <jarek>
http://en.wikipedia.org/wiki/Buzzword

[14:09:59.0000] <jarek>
actually, I think you are right :)

[14:20:03.0000] <tantek>
Hixie, that's pretty good.

[14:20:33.0000] <tantek>
I'd more strongly emphasize key adjectives in the opening "First, " sentence

[14:20:36.0000] <tantek>
e.g. right now you have: "First, write a description of the problem"

[14:20:49.0000] <tantek>
I'd say something like: "First, write a brief user-centric description of the problem."

[14:20:59.0000] <tantek>
I think what you're calling "high-level", I'd call user-centric

[14:21:45.0000] <tantek>
for example, "need a native triple-store" reads like a high-level description of a problem

[14:21:48.0000] <tantek>
but has nothing to do with the user

[14:21:59.0000] <tantek>
hence I prefer the term user-centric rather than high-level for these things

[14:22:37.0000] <tantek>
this is certainly very good: "0. Discuss the topic on our IRC channel (#whatwg on Freenode) to see if you've missed anything obvious "

[14:24:33.0000] <tantek>
interestingly enough, that page seems to assume people already have some experience with HTML - which is a reasonable assumption

[14:25:06.0000] <tantek>
though I bet a lot of folks coming up with feature requests don't realize there's already something in HTML (or CSS, or JS, or WebAPIs) that satisfies their use case

[14:25:26.0000] <tantek>
with microformats, we've had to make that implicit step explicit: http://microformats.org/wiki/process#Get_some_experience_first

[14:26:15.0000] <gavinc>
Perhaps a link to a web interface to IRC?

[14:26:24.0000] <gavinc>
as otherwise step 0 may be a large one

[14:27:00.0000] <tantek>
the subsequent section, "Why?"  http://microformats.org/wiki/process#Why.3F is similar to the start of "How you can improve HTML "

[14:27:23.0000] <tantek>
gavinc - excellent idea - feel free to improve http://wiki.whatwg.org/wiki/Irc accordingly

[14:28:21.0000] <tantek>
(now linked from that step 0)

[14:28:37.0000] <Wilto>
Would ALA editor feedback be helpful at this point?

[14:29:12.0000] <tantek>
gavinc - also, feel free to copy from http://microformats.org/wiki/irc#Quick_Start which provides some minimal setup/web interface info

[14:36:26.0000] <Yuhong>
tantek: Noticed I mentioned your suggestion to modularize HTML on HN.

[14:36:53.0000] <tantek>
Yuhong - thanks! Hopefully we'll get some additional discussion.

[14:37:14.0000] <Yuhong>
tantek: Based on the fact that the "HTML5" buzzword will not disappear tomorrow.

[14:37:23.0000] <Yuhong>
http://news.ycombinator.com/item?id=4336924

[14:37:27.0000] <tantek>
so we might as well take advantage of that

[14:37:56.0000] <tantek>
Yuhong, also, since you're here often enough, add yourself to http://wiki.whatwg.org/wiki/IRC

[14:44:43.0000] <gavinc>
tantek: will do

[14:54:56.0000] <tobie>
Hixie: that's exactly what I had in mind.

[15:19:03.0000] <Hixie>
tantek, jgraham: updated, thanks.

[15:19:40.0000] <Hixie>
tobie: cool

[15:19:41.0000] <Hixie>
Wilto: sure

[16:03:56.0000] <Hixie>
wait, the HTML test suite isn't MIT licensed?

[16:07:48.0000] <zewt>
heh <zewt> jgraham: are there any requirements on test licensing to make sure the tests can be reused? (eg. by whatwg)

[16:08:28.0000] <Hixie>
forget whatwg, what about browser vendors??

[16:09:13.0000] <zewt>
they don't necessarily even need a license to be able to run the tests, but you definitely need one to modify them

[16:09:56.0000] <Hixie>
browser vendors import the tests into their repos (which means they need a license to copy them) and modify them to fit their needs (so, they need to modify them)

[16:10:14.0000] <Hixie>
ironically, we'd need less of a license since we'd only need to describe diffs

[16:10:23.0000] <Hixie>
which don't necessarily require anything beyond fair use

[16:10:32.0000] <Hixie>
if that

[16:11:04.0000] <zewt>
a widely-debated topic, from what i recall

[16:11:41.0000] <zewt>
(recalling good old DJB and his "no modifications allowed, not even patches" licensing)

[16:12:16.0000] <Hixie>
many things are widely debated

[16:12:22.0000] <zewt>
that is so

[16:12:25.0000] <Hixie>
e.g. whether humans affect the climate

[16:12:33.0000] <Hixie>
whether species evolve from each other

[16:12:52.0000] <Hixie>
doesn't mean there's any actual question as to the matter :-)

[16:13:05.0000] <zewt>
you're aware "fair use" doesn't even exist in many countries, right? :)

[16:13:17.0000] <Hixie>
i am

[16:17:08.0000] <tantek>
the test suites should be placed in the public domain (per CC0) just like everything else.

[16:17:12.0000] <tantek>
(in standards)

[16:17:39.0000] <Hixie>
that's what i had assumed was the case, but recent e-mails suggest it may not be

[16:18:13.0000] <Hixie>
tantek: btw i updated the wiki page, let me know if you have further comments. Regarding your comment about it sounding like it was aimed at web devs rather than users: it is; specifically, it's intended for a list apart.

[16:24:08.0000] <tantek>
Hixie - looks good

[16:24:24.0000] <tantek>
any further iteration can happen lazily / as-needed

[16:27:10.0000] <tantek>
is there an ALA article in the works about "How to improve HTML?"

[16:28:25.0000] <Hixie>
yes, that wiki section

[16:29:09.0000] <Hixie>
heycam|away: ping (re: making the concept of 'global environment' broader than just for JS in webidl, so that I don't have to be JS-specific in defining the three kinds of global environments in the web)

[16:36:54.0000] <tantek>
Hixie, re: PD(CC0) test cases, perhaps we could make such an encouragement (to make test cases all explicilty PD/CC0) on the wiki page: http://wiki.whatwg.org/wiki/Test_cases

[16:37:41.0000] <Hixie>
i doubt that wiki page would have any impact on the relevant folk :-)

[16:37:44.0000] <Hixie>
but feel free to do so

[16:38:00.0000] <tantek>
and http://wiki.whatwg.org/wiki/Testsuite

[16:38:20.0000] <tantek>
i find it hard at times to guess a priori who the "relevant folk" are

[16:38:58.0000] <tantek>
by posting things on a wiki page, it increases the chance that new folks will pick up the suggestions and incorporate them

[16:39:04.0000] <tantek>
ok

[16:39:20.0000] <Hixie>
relevant folk in this case is whoever at the w3c is in charge of picking a license

[16:40:03.0000] <tantek>
I'd rather that individuals just post PD/CC0 test cases to the web, and then anyone can aggregate/curate them, no need for W3C to be a bottleneck

[16:41:09.0000] <Hixie>
the gap between what i'd rather be happening here and what is actually happening here is a vast chasm that rivals some of the most impressive natural canyons known to man

[16:41:16.0000] <Hixie>
but yes, in principle i completely agree

[16:41:27.0000] <tantek>
sounds good, I'll make a note of it

[16:44:49.0000] <tantek>
Hixie, all the CSSWG tests are available under 3-clause BSD in addition to whatever bespoke W3C license: http://www.w3.org/Style/CSS/Test/Overview.en.html

[16:44:56.0000] <tantek>
so there is that

[16:45:08.0000] <Hixie>
i thought the html tests were under the mit license

[16:45:26.0000] <Hixie>
glad at least one group is doing things right

[16:45:27.0000] <tantek>
I suppose I could push to switch from BSD to PD/CC0 and see what happens

[16:45:46.0000] <Hixie>
there's essentially no important difference between pd/cc0, bsd, and mit

[16:46:04.0000] <Hixie>
i prefer mit because it's shorter, personally

[16:46:59.0000] <tantek>
I prefer CC0 because it's more internationalized

[16:47:06.0000] <tantek>
and shorter (by reference)

[16:47:26.0000] <Hixie>
"shorter by reference"?

[16:51:04.0000] <tantek>
yes, it's a one sentence declaration that incorporates the CC0 declaration by hyperlink (with rel=license)

[16:51:14.0000] <tantek>
no need to include all the mumbo jumbo in every document.

[16:52:08.0000] <Hixie>
well you can do the same for the MIT license, that's a non-issue. In fact you don't even need to mention the MIT license, so long as it's in the relevant package somewhere.

[16:52:48.0000] <zewt>
(personally I always avoid linking licenses, since I can't prove that the thing it points to will never change, or always be there)

[16:54:08.0000] <tantek>
zewt - seems to have worked ok for Creative Commons for 8+ years. let me know when you hear of an actual (rather than theoretical) problem of that occurring.

[16:54:52.0000] <zewt>
uh huh, because sites never go down

[16:55:01.0000] <zewt>
be sloppy with licensing matters if you like

[16:55:06.0000] <tantek>
just saying in practice it has not posed a problem for CC

[16:55:14.0000] <tantek>
so let me know when you hear of an actual problem

[16:55:21.0000] <tantek>
rather than handwaving about how problems might happen all the time

[16:58:32.0000] <zewt>
(sorry, I find you consistently rude and talking to you makes me irritable, so I'm going to avoid doing so)

[16:59:21.0000] <tantek>
zewt I'm concisely pointing out flaws with your reasoning, if you think that's rude, perhaps avoid debate altogether.


2012-08-09
[17:00:19.0000] <Hixie>
on a more productive note, does anyone know where we create the javascript global environment for browsing contexts?

[17:00:28.0000] <Hixie>
i'm drawing a blank here

[17:10:15.0000] <Hixie>
/me tries to figure out where it should be happening, since it doesn't appear to be happening anywhere

[17:10:18.0000] <Hixie>
sweet lord what a tangled web we weave

[17:10:25.0000] <Hixie>
ok so one Window can have two Documents

[17:10:32.0000] <Hixie>
but can one Document ever have two Windows?

[17:10:53.0000] <Hixie>
oh, right, document.open()

[17:10:54.0000] <Hixie>
crap

[17:11:00.0000] <Hixie>
jesus this is messed up

[17:12:10.0000] <Hixie>
i guess the question is, given that all singletons and interface objects, etc, get reset when you do document.open(), is it still nonetheless the same javascript global environment?

[17:16:54.0000] <Hixie>
i like how y'all are full of opinions on highly complicated legal matters like which license is best but when it comes to our bread and butter y'all shut up :-P

[17:22:57.0000] <tantek>
/me was away editing wiki pages

[17:23:06.0000] <tantek>
Hixie, http://wiki.whatwg.org/wiki/Test_cases updated

[17:23:26.0000] <tantek>
and this section added as well: http://wiki.whatwg.org/wiki/Testsuite#How_to_license_your_test_suite

[17:23:31.0000] <tantek>
feel free to tweak

[17:25:09.0000] <Hixie>
cool

[17:25:58.0000] <Hixie>
(anyone know of a way to test is a plugin is being instantiated when the plugin is invisible? my test flash files all just display words like "PASS", they don't have audio or expose APIs...)

[17:26:04.0000] <tantek>
at least we have something to point to when people ask us how to do it

[17:26:50.0000] <tantek>
Hixie, would a plugin that just changed the <title> count as invisible?

[17:29:33.0000] <heycam>
Hixie, pong. was that the bug 15158 you just changed?

[17:30:10.0000] <Hixie>
tantek: sure, do you have one?

[17:30:15.0000] <Hixie>
heycam: yeah

[17:30:27.0000] <heycam>
will review

[17:30:29.0000] <Hixie>
heycam: please see the diff and let me know how crazy i am

[17:30:31.0000] <abarth>
Hixie: I can try to answer these questions

[17:30:33.0000] <tantek>
/me avoids writing plugin code.

[17:31:10.0000] <abarth>
Hixie: There should be a one-to-one relationship between DOMWindow and Document

[17:31:10.0000] <Hixie>
i wrote a debug NPAPI plugin long ago when reverse engineering <object>, but I don't really want to dig it up, let alone recompile it for 64 bit :-)

[17:31:18.0000] <Hixie>
abarth: there definitely isn't :-)

[17:31:23.0000] <abarth>
Hixie: why not?

[17:31:57.0000] <Hixie>
abarth: e.g. Document objects get reused when you call document.open(), even though the Window changes, and the Window gets reused for two Document objects when you load a page into a frame with about:blank loaded in certain cases.

[17:32:24.0000] <Hixie>
(also there's no such thing as DOMWindow, it's just Window :-P)

[17:32:44.0000] <abarth>
Hixie: You can dance around those, if you want

[17:32:58.0000] <tantek>
perhaps there's an Actionscript Hello World DOM example somewhere that could be modified to set document.title="PASS";

[17:32:59.0000] <abarth>
in the second case, you can just move all the properties over

[17:33:03.0000] <abarth>
and update the WindowProxy as usual

[17:33:37.0000] <abarth>
/me goes and checks on the first case

[17:34:31.0000] <Hixie>
abarth: well fundamentally my question is the same one as for heycam... basically, do we need to say when we create the global environment?

[17:34:39.0000] <Hixie>
or rather, where should we say to

[17:34:54.0000] <Hixie>
see the most recent checkin for the hack that i came up with

[17:34:57.0000] <Hixie>
in the meantime

[17:35:06.0000] <Hixie>
anyway: afk for a bit, heading home

[17:35:24.0000] <abarth>
Hixie: in the first case, it looks like we just remove event listeners

[17:35:50.0000] <hoolter>
Why do @src-full <script>s need a closing tag?

[17:36:22.0000] <abarth>
Hixie: yeah, the global variables are still there:

[17:36:27.0000] <abarth>
> window.foo ="hi"

[17:36:32.0000] <abarth>
> document.open()

[17:36:38.0000] <abarth>
> document.write("<script>alert(window.foo)</script>")

[17:39:38.0000] <hoolter>
abarth: not sure what the idea is, but you'll want to actually do doc.write('<script>alert(win.foo)<'+'/sc'+'ript>)....

[17:39:58.0000] <abarth>
hoolter: oh, i was typing in the web inspector

[17:40:15.0000] <hoolter>
abarth: ah, ok.

[17:42:24.0000] <tantek>
Hixie, re: the relevant people at W3C, it appears that this W3C page makes it clear that W3C test suites are supposed to all be available under BSD for implementations etc. : http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright

[17:42:41.0000] <tantek>
(more than just the CSSWG)

[17:43:05.0000] <tantek>
so whoever is saying the W3C HTML5 tests are not liberally licensed (or should / should not be) or so might want to take a look at that

[17:48:22.0000] <MikeSmith>
tantek: yeah that's my understanding as well

[17:49:21.0000] <MikeSmith>
tantek: I think the message Hixie has in mind was http://lists.w3.org/Archives/Public/public-test-infra/2012JulSep/0031.html

[17:49:32.0000] <MikeSmith>
Kris Kruger from Microsoft

[17:49:55.0000] <MikeSmith>
saying "the license issue is a blocker"

[17:49:55.0000] <MikeSmith>
d

[17:50:07.0000] <MikeSmith>
I don't understand what license issue he means

[17:55:19.0000] <MikeSmith>
tantek: I suspect that he just means the need for people to complete the license grant at https://www.w3.org/2002/09/wbs/1/testgrants2-200409/

[17:56:08.0000] <MikeSmith>
but we can have people complete that even if we host the tests elsewhere

[17:56:45.0000] <MikeSmith>
the location where they're hosted is orthogonal to the license agreement

[17:57:33.0000] <MikeSmith>
I hope nobody's suggesting we accept test cases without having license grants on file from the people who contributed them

[17:58:11.0000] <MikeSmith>
for one thing, if we don't have that, it might prevent other free-software projects from being able to redistribute the test suites

[17:59:50.0000] <MikeSmith>
Debian project for example are keen on checking to make sure everything they package is in fact free, with documentation about who contributed and a record of them agreeing to freely license their contributions

[18:25:05.0000] <gsnedders>
MikeSmith: Really? That surprises me given the relatively small number of projects that require CLAs.

[18:25:37.0000] <MikeSmith>
gsnedders: well, that ask at least

[18:25:54.0000] <MikeSmith>
I don't think the require the details always, but they prefer them

[18:26:30.0000] <MikeSmith>
I know because I've been contacted before by Debian packagers asking for records

[18:26:48.0000] <gsnedders>
Yeah. I can see there's aso going to be more doubt over higher-profile projects where there's more to gain by getting stuff in without proper grants.

[18:27:02.0000] <MikeSmith>
right

[18:27:47.0000] <MikeSmith>
and especially when some contributors are working for companies that have software patents

[18:32:35.0000] <jamesr_>
i thought CLAs are typically about copyright, not patents

[18:35:10.0000] <MikeSmith>
jamesr_: yeah true. so maybe my comment is a non-sequitor

[18:57:04.0000] <gsnedders>
jamesr_: Combined with something like the Apache License, though, it would be.

[19:16:12.0000] <tantek>
MikeSmith from reading that thread I don't understand what the problem is either

[19:16:45.0000] <tantek>
I just tell folks to contribute the entirety of their test suites to the public domain with CC0 and then it lets anyone else do whatever with them.

[19:17:33.0000] <tantek>
i.e. do this and don't worry about it: http://wiki.whatwg.org/wiki/Testsuite#How_to_license_your_test_suite

[19:17:58.0000] <tantek>
if someone else wants to incorporate your work and relicense with BSD (e.g. W3C) great. but keep the core in the public domain where the community iterates on it.

[19:18:27.0000] <tantek>
so to that extent, I'd advocate for putting tests suites on github with PD/CC0 and then let W3C or whoever else incorporate them downstream

[19:29:54.0000] <tantek>
BTW with regards to getting contributor agreements on github, since github itself doesn't have a contributor agreement mechanism, here's what I've done with one of my projects: https://github.com/tantek/cassis/blob/master/contributors.txt

[00:08:05.0000] <jgraham>
Hixie: Testsuites are W3C/BSD dual licensed (I guess someone else already said that... reading)

[00:11:12.0000] <jgraham>
Also, it is the same global environment after document.open isn't it?

[00:24:53.0000] <jgraham>
(and what makes you think I would contribute to, or encorage others to contribute to, a testsuite with crappy licensing :)

[01:16:03.0000] <odinho>
Ms2ger: startTime did exist before. They probably found some old TR to cuddle up with.

[01:19:40.0000] <jgraham>
/me remembers he was having a nightmare about being at a HTMLWG F2F

[01:19:42.0000] <odinho>
/me want a wiki user.

[01:20:19.0000] <jgraham>
annevk and rubys were there. And I turned up late. This is all I remmeber.

[01:26:20.0000] <odinho>
Hehe. My first (and only) htmlwg meeting, me and annevk was always super early because we were badly out of sync with the time :]

[01:54:03.0000] <Ms2ger>
odinho, I see

[01:54:23.0000] <Ms2ger>
odinho, the fun part is that the test passes because 0 == undefined

[01:54:32.0000] <jgraham>
Hahaha

[01:54:34.0000] <odinho>
cool

[01:54:40.0000] <odinho>
some forward thinking on their part there

[01:55:00.0000] <jgraham>
Pointer?

[01:55:53.0000] <Ms2ger>
tests/approved/video/video_007.htm

[01:57:14.0000] <Ms2ger>
Also fun: video_001.htm and video_006.htm are identical

[01:57:40.0000] <odinho>
Can't be too sure, you know.

[01:57:53.0000] <jgraham>
That seems to be from intel?

[01:58:08.0000] <jgraham>
Also it is obviosuly rejected on the basis it doesn't use testharness.js

[01:58:16.0000] <jgraham>
Oh wait

[01:58:20.0000] <jgraham>
I am confused again

[01:58:26.0000] <jgraham>
Silly silly hgweb

[01:58:36.0000] <odinho>
Yeah, it is supremely silly.

[01:58:54.0000] <odinho>
When I had the last commit, I had someone ask me about a totally random test.

[02:48:58.0000] <hoolter>
Why do @src-full <script>s need a closing tag?

[02:49:55.0000] <Ms2ger>
Because otherwise the rest of the page is eaten

[02:55:14.0000] <AryehGregor>
Hmm.  So why is cp --reflink=auto not the default in GNU cp?

[02:55:20.0000] <AryehGregor>
/me is looking to start using btrfs

[02:55:32.0000] <AryehGregor>
Maybe I should ask in #btrfs instead of spamming random channels.

[02:55:43.0000] <AryehGregor>
Novel concept.

[03:11:06.0000] <odinho>
AryehGregor: Sounds like work.

[03:11:22.0000] <AryehGregor>
If it were work, I would be paid for it.  :)

[03:11:31.0000] <odinho>
I've been running btrfs for a long time though. Totally nice.

[03:12:33.0000] <AryehGregor>
/me has ordered two SSDs to move all his code onto, since he's tired of waiting for operations like "hg qpush" that scan the disk

[03:12:50.0000] <AryehGregor>
/me figures he'll make it btrfs just for kicks, while he's at it, since it's all backed up and readily replaceable

[03:13:44.0000] <jgraham>
/me spends very little of his life thinking "oh here's a problem that would be solved if only I had a different filesystem"

[03:14:59.0000] <AryehGregor>
I like filesystems!  They're interesting.

[03:15:08.0000] <AryehGregor>
Also, snapshots and cp --reflink are really nice.

[03:15:37.0000] <AryehGregor>
I'm betting cp -a --reflink on my SSDs will copy an entire mozilla-central checkout (a few gigs) in under a second.

[03:15:47.0000] <AryehGregor>
Which I have to do periodically, like to recover from corruption.

[03:15:48.0000] <jgraham>
I think they are probably theoretically very interesting

[03:16:02.0000] <AryehGregor>
Because Mercurial, hey, Mercurial's all about randomly corrupting your data.

[03:16:15.0000] <AryehGregor>
Also, there have been times when I'd have loved a snapshot that I could easily roll back to.

[03:16:20.0000] <jgraham>
YOu gave up on git?

[03:16:28.0000] <AryehGregor>
But rsnapshot is ridiculously too expensive.

[03:16:49.0000] <AryehGregor>
No, but Mozilla uses hg, so I was giving hg a chance to prove that it's not intolerable.

[03:16:59.0000] <AryehGregor>
I've more or less given up, hg is just fundamentally broken.

[03:17:13.0000] <AryehGregor>
But I have to spend some time to switch to git and change my workflow accordingly.

[03:17:25.0000] <AryehGregor>
hg-git has been flaky in my experience.

[03:18:15.0000] <jgraham>
Were you using the cdouble-approved workflow?

[03:18:28.0000] <AryehGregor>
What?

[03:18:47.0000] <jgraham>
http://www.bluishcoder.co.nz/2011/04/16/my-git-workflow-for-mozilla-development.html

[03:19:34.0000] <hoolter>
Ms2ger: but why can't the parser be smart about whether it has a @src or not?

[03:19:49.0000] <AryehGregor>
Hmm, interesting.

[03:20:02.0000] <AryehGregor>
hoolter, it can, but the decision was made like 15 years ago and it's too late to change it.

[03:20:08.0000] <jgraham>
My experience with the W3C repos is that workflow, which avoids using the push/pull in hg-git works better than workflows that depend on those)

[03:20:13.0000] <jgraham>
s/)//

[03:20:27.0000] <AryehGregor>
Yeah, that workflow makes a lot of sense.

[03:20:30.0000] <Ms2ger>
Speaking of W3C repos

[03:20:40.0000] <Ms2ger>
Do you guys have web audio tests?

[03:20:55.0000] <AryehGregor>
Use git read-only for development, and push actual patches using hg directly.

[03:22:12.0000] <jgraham>
Ms2ger: What do you mean Web Audio?

[03:22:28.0000] <jgraham>
Do you mean the Google thing, or the Mozilla thing or the <audio> element?

[03:22:34.0000] <jgraham>
Or some other thing?

[03:38:50.0000] <Ms2ger>
The Mozilla thing, I guess

[06:04:47.0000] <hoolter>
AryehGregor: why is it too late to change it though?

[06:05:23.0000] <AryehGregor>
hoolter, because countless millions of pages almost certainly depend on it and will break if we change it?

[06:05:36.0000] <AryehGregor>
And users tend to stop using browsers that break the pages they visit?

[06:06:00.0000] <AryehGregor>
And browsers compete intensely, so that even a modest number of users who stop using a browser is something that everyone tries to avoid at all costs?

[06:06:30.0000] <jgraham>
I think Opera allowed that syntax for a while and I am not sad we stopped allowing it

[06:06:39.0000] <AryehGregor>
Did it have compat issues?

[06:07:10.0000] <jgraham>
Almost certainly, but I don't have specific bugs in mind

[06:08:09.0000] <jgraham>
HTML parsing really needs nothing more than people to just leave it alone

[06:08:29.0000] <AryehGregor>
Yes.

[06:08:31.0000] <jgraham>
Incremental gains in friendliness at the risk of compat breakage are not worth it

[06:22:08.0000] <AryehGregor>
Trying to make HTML parsing more predictable and user-friendly is putting lipstick on a pig anyway.

[07:46:55.0000] <Hixie>
othermaciej, hsivonen: i'm baffled by this idea of reusing <meta> or <link>. Should we just have every void element from now on use <meta>? Even though it's already overloaded a zillion ways to sunday?

[07:53:35.0000] <jgraham>
Hixie: Yes, especially if it is going in <head>

[07:54:10.0000] <jgraham>
Just like we reuse <input> for compat reasons rather than inventing <datepicker>

[07:54:48.0000] <Hixie>
that sounds crazy to me

[07:55:00.0000] <jgraham>
Why?

[07:55:03.0000] <Hixie>
the cost of a new void element is de minimis compared to the cost of overloading these elements more

[07:55:18.0000] <jgraham>
That's really not true

[07:55:27.0000] <jgraham>
The cost of a new void element to us is huge

[07:55:32.0000] <Hixie>
o_O

[07:55:42.0000] <jgraham>
I mean it's trivial to add in the code

[07:56:00.0000] <jgraham>
But every day that we don't ship it and someone else does it's a compat liability

[07:56:14.0000] <jgraham>
Which just doesn't exist with an existing void element

[07:56:26.0000] <Hixie>
we've added tons of void elements over the years

[07:56:37.0000] <jgraham>
Not really

[07:56:58.0000] <jgraham>
We added <source> which had the </video> get-out-of-jail-free card

[07:57:35.0000] <Hixie>
apple added <canvas> and the only reason that was a problem is that we ended up not wanting it to be void

[07:57:44.0000] <jgraham>
I can't think of anything that we added to <head> for over a decade

[07:58:18.0000] <Hixie>
<wbr> was added at some random point, as was <keygen>

[07:58:42.0000] <Hixie>
we added <track> at some point, and it, like <source>, is essentially in the <head> of a block of content intended specifically for legacy UAs

[07:58:54.0000] <jgraham>
<keygen> was added in netscape 4 times, so also long ago, and before CSS or scripting took off

[07:59:02.0000] <Hixie>
i really don't see the problem with adding something to <head>

[07:59:29.0000] <jgraham>
These days the compat risks are much higher because everything depends on the precise form of the DOM

[08:00:01.0000] <Hixie>
i'm highly skeptical

[08:00:13.0000] <Hixie>
if there was any evidence that'd be one thing

[08:00:18.0000] <jgraham>
I'm highly skeptical that it's safe

[08:00:21.0000] <Hixie>
but this is just FUD, imho

[08:00:39.0000] <Hixie>
we should take risks, not play things so safe that we make the language even more ludicrous than it already is

[08:01:05.0000] <jgraham>
Well we have a whole design principle about back-compat and three browser vendors telling you they don't like the design :)

[08:01:31.0000] <Hixie>
this doesn't break any existing content

[08:02:14.0000] <jgraham>
It also doesn't degrade gracefully

[08:02:32.0000] <Hixie>
come now

[08:02:34.0000] <Hixie>
it degrades fine

[08:02:48.0000] <jgraham>
It you are seriously careful about how you use it

[08:02:55.0000] <Hixie>
you don't even have to be careful

[08:02:59.0000] <jgraham>
Which I don't trust authors to be

[08:03:02.0000] <Hixie>
any problems you might run into are immediately obvious

[08:03:30.0000] <Ms2ger>
If you test in Opera

[08:03:32.0000] <jgraham>
If you test on a browser that doesn't have support

[08:05:08.0000] <jgraham>
Ms2ger: Or Mobile Firefox, for example

[08:05:30.0000] <Ms2ger>
Meh, I don't care about Mobile Firefox

[08:05:51.0000] <jgraham>
Just as well you don't wnt to be paid by MozCo then ;)

[08:06:22.0000] <Ms2ger>
I think I'll do fine :)

[08:06:24.0000] <jgraham>
Hixie: Anyway the sad truth is that, particularly on mobile, developers can't be trusted to test well

[08:06:52.0000] <Hixie>
this cost is so small i'm struggling to care at all

[08:07:00.0000] <Ms2ger>
/me grumbles about not being able to use std::numeric_limits<T>::min()/max() for [Clamp]

[08:07:00.0000] <Hixie>
compared to the cost of never being able to add more elements

[08:07:15.0000] <Hixie>
we've added some before without any trouble

[08:07:17.0000] <Ms2ger>
Hixie, more *void* elements

[08:07:20.0000] <Hixie>
this is completely hypothetical

[08:07:43.0000] <jgraham>
We added one in over a decade

[08:07:51.0000] <Hixie>
we've added at least two just to <video>

[08:08:03.0000] <Hixie>
where they specifically affect legacy UAs

[08:08:04.0000] <jgraham>
Oh, is track also void?

[08:08:18.0000] <Hixie>
and we added canvas before it was changed

[08:08:23.0000] <jgraham>
But the </video> container limits the damage there

[08:08:27.0000] <Hixie>
and wbr and keygen and img before that

[08:08:33.0000] <jgraham>
and void canvas wasn't widely deployed

[08:08:42.0000] <Hixie>
it limits the damage _specifically to legacy UAs that don't support the element_

[08:09:00.0000] <jgraham>
and wbr and keygen and img are over a decade ago and predate anyone using scripts or css selectors

[08:09:05.0000] <Hixie>
if we try this and find that it really causes damage, then sure, it would make sense to avoid it

[08:09:14.0000] <jgraham>
So they are super-weak examples

[08:09:17.0000] <Hixie>
but avoiding it just because of theoretical concerns is silly and chicken

[08:09:30.0000] <Hixie>
my point is that however weak, they are examples of it working

[08:09:36.0000] <Hixie>
we have _zero_ examples of it not working

[08:09:41.0000] <jgraham>
My point is that they are irrelevant

[08:09:42.0000] <Hixie>
not even weak ones

[08:13:50.0000] <darobin>
or we could just grant /> magical close behaviour and require it on new void elements!

[08:13:54.0000] <darobin>
/me runs away giggling

[08:14:29.0000] <jgraham>
(btw, I don't think it's reasonable to characterise arguments as "chicken" when you are not one of the parties assuming any of the risk)

[08:16:34.0000] <Hixie>
my salary is indirectly driven from the success of four browser vendors and of the web platform as a whole, and my ability to perform my job is directly related to how much browser vendors trust me which would drop if i was wrong, so i wouldn't say i'm not assuming any of the risk

[08:37:33.0000] <dglazkov>
good morning, Whatwg!

[08:37:40.0000] <dglazkov>
whoa, excellent discussion on tags

[08:38:38.0000] <MikeSmith>
are we any closer to interoperability on drag and drop than we were when ppk wrote http://www.quirksmode.org/blog/archives/2009/09/the_html5_drag.html 3 years ago?

[08:39:18.0000] <Hixie>
over the last three years UAs have definitely changed their drag and drop implementations

[08:39:22.0000] <Hixie>
whether we're any closer, i dunno

[08:39:37.0000] <Hixie>
i did notice that webkit implemented the dropzone thing, but for reasons that baffle me they prefixed it

[08:40:35.0000] <jgraham>
We have a pile of tests that we ought to release

[08:40:48.0000] <jgraham>
But for obviosu reasons they are mostly manual tests

[08:41:17.0000] <odinho>
We have a runner :]

[08:41:27.0000] <dglazkov>
Hixie: prefixing in WebKit is a bit of a cargo cult

[08:43:05.0000] <jgraham>
odinho: I heard something about perl scripts and then got scared

[08:43:53.0000] <jgraham>
Automating dragging from the desktop to the browser seems very difficult to make reliable to me

[08:44:08.0000] <odinho>
jgraham: Oh, scary indeed. I just see the tests running every day, because giorgic's screen is very viewable from here.

[08:46:16.0000] <jgraham>
Anyway, I think it's better to go with the simpler interpretation that "they're manual tests"

[08:46:58.0000] <odinho>
jgraham: Sure

[08:53:58.0000] <AryehGregor>
Wait, so what's the big problem specifically with void tags?  I'd have thought the bigger problem would be introducing new tags that are allowed in <head> -- if authors aren't careful to put them after things like <title>, which they won't be, it will break the page in browsers that treat them as an implicit <body> start, no?

[08:54:17.0000] <AryehGregor>
New void tags will break things like .lastChild, I guess.

[08:54:29.0000] <AryehGregor>
But I'm actually moderately skeptical that that would be a real problem in practice.

[08:54:54.0000] <AryehGregor>
In particular, the compat hit only hits old browsers, right?

[08:55:23.0000] <AryehGregor>
So as long as all browsers coordinate to deploy support at roughly the same time, it doesn't seem like a big problem.

[08:55:41.0000] <AryehGregor>
Authors don't deploy new features *that* fast.

[08:56:08.0000] <Hixie>
especially with browsers moving to release cycles measured in weeks rather than years

[08:56:42.0000] <Ms2ger>
Except IE

[08:56:46.0000] <Ms2ger>
And except Safari

[08:56:54.0000] <Ms2ger>
And except every mobile browser

[08:57:06.0000] <Hixie>
i said "moving", not that they were all there already

[08:57:22.0000] <jgraham>
AryehGregor: When did browsers ever coordinate to deploy things at the same time?

[08:57:36.0000] <AryehGregor>
jgraham, doesn't mean they can't.

[08:57:43.0000] <jgraham>
But yes, for the specific case of new elements in <head> there are even more problems than new elements in general

[08:57:46.0000] <Ms2ger>
In the nineties, I hear

[08:57:47.0000] <Hixie>
HTML parser was implemented by pretty much everyone very close to each other

[08:57:51.0000] <AryehGregor>
Also: why do we care if it hurts IE and Safari?  :)

[08:57:52.0000] <jgraham>
+void

[08:58:03.0000] <AryehGregor>
Hixie, um, a couple years apart, no?

[08:58:08.0000] <jgraham>
Hum? IE still hasn't shipped that

[08:58:22.0000] <jgraham>
And won;t ever on the platforms that most IE users currently use

[08:58:30.0000] <Hixie>
AryehGregor: that's about as close as i can imagine it happening

[08:58:50.0000] <AryehGregor>
But really, I don't see the big risk in something where the compat hit will only affect old browsers.

[08:59:06.0000] <AryehGregor>
I'd even say compatibility of new pages with old browsers should be an explicit non-goal.

[08:59:22.0000] <AryehGregor>
Obviously pages that use new features might not work in old browsers if they're not specifically tested.

[08:59:23.0000] <jgraham>
AryehGregor: You mean "any browser that doesn't implement the feature yet"

[08:59:44.0000] <AryehGregor>
jgraham, well, yes, but if you're just worried about that, you can always do a quick parser fix to avoid any compat fallout.

[08:59:56.0000] <AryehGregor>
You don't have to implement the interfaces or anything, even as stubs.

[09:00:09.0000] <AryehGregor>
It should be the work of like an hour or two.

[09:00:15.0000] <Hixie>
anyone have any way to test if a plugin is instantiating or when the plugin isn't visible?

[09:00:23.0000] <jgraham>
and I think it is very problematic to design features in ways that favours accidential breakage even if there is no need for the whole page to fail

[09:01:01.0000] <jgraham>
AryehGregor: I would absolutely advocate us doing that if we are forced to.

[09:01:03.0000] <Hixie>
s/or/or not/

[09:01:08.0000] <jgraham>
I don't want to be forced to

[09:01:17.0000] <AryehGregor>
jgraham, why not?  What's the cost?

[09:01:27.0000] <Hixie>
you wouldn't be forced to

[09:01:33.0000] <Hixie>
there just isn't a real risk here imho

[09:01:52.0000] <jgraham>
Hixie: If you insist on using this design and webkit deploy it we would be forced to

[09:01:53.0000] <AryehGregor>
Especially for regular old void elements, which can only cause serious failures in relatively uncommon circumstances.

[09:02:02.0000] <Hixie>
jgraham: i highly doubt it

[09:02:16.0000] <AryehGregor>
Hixie, I think adding new elements to <head> is a more serious risk, though.  All that would take to break non-implementing browsers is authors putting it before the <title> or something.

[09:02:39.0000] <jgraham>
Hixie: Under those circumstances I would change our parser

[09:03:01.0000] <Hixie>
AryehGregor: how so?

[09:03:31.0000] <Hixie>
jgraham: (on the other hand "if you insist" on it using <meta> or <link> then we have a language that's even harder to understand, forever. not clear to me that you're optimising for the right thing. potential transient risk vs bad language forever.)

[09:03:40.0000] <AryehGregor>
Hmm, so <title> still works if it's in the <body>?

[09:03:50.0000] <jgraham>
Hixie: Now you sound like a member of the XHTML 2 WG

[09:03:57.0000] <AryehGregor>
Yeah, I was going to say.

[09:04:11.0000] <jgraham>
I don't think <link re=intent> or <link intent> is hard to understand

[09:04:20.0000] <AryehGregor>
Since when does the WHATWG support long-term hypothetical benefits over short-term implementability?

[09:04:24.0000] <Hixie>
AryehGregor: everything still works in the <body>, there are too many pages that have a random non-head character (e.g. two BOMs) as the first character

[09:04:29.0000] <AryehGregor>
Ah, okay.

[09:04:36.0000] <AryehGregor>
Then I guess I don't see a problem.

[09:04:42.0000] <Hixie>
jgraham: it doesn't fit with <link>'s processing model at all

[09:05:10.0000] <jgraham>
Hixie: Is that a practical concern or a spec-author concern?

[09:05:26.0000] <Hixie>
and re the xhtml2 insult (:-P), there's a world of difference between caring about both transitions and long-term quality and not caring at all about transition

[09:05:42.0000] <Hixie>
so i don't think it's at all equivalent

[09:06:23.0000] <Hixie>
jgraham: consider the messes that <input> or <object> are because of overloading already

[09:06:30.0000] <Hixie>
jgraham: or indeed, <meta> already

[09:06:38.0000] <jgraham>
<input> is a success story

[09:06:47.0000] <jgraham>
<object> is not ofc

[09:06:49.0000] <Hixie>
jgraham: yes, it causes all kinds of problems for authors. tutorials and documentation are all kinds of complicated because of it

[09:07:07.0000] <Hixie>
<input> is a success story for us, but i don't think most authors see it that way

[09:07:33.0000] <Hixie>
and to be honest, it's a success story partially because of our heroic work trying to keep it sane in wf2 and html, when adding new features

[09:07:43.0000] <Hixie>
which was no small feat imho

[09:08:27.0000] <jgraham>
I don't see why <link> couldn't also be a success. This is a much smaller problem (we are trying to add one feature not a dozen)

[09:08:36.0000] <Hixie>
<link> is already a confusing mes

[09:08:37.0000] <Hixie>
s

[09:08:38.0000] <dglazkov>
<input> is a "despite all odds" success story. The basic design sucks. I hope everyone agrees on that.

[09:08:45.0000] <Hixie>
hear hear

[09:08:58.0000] <jgraham>
s/input/HTML/

[09:10:10.0000] <jgraham>
I don't think we could have done better than <input> in the circumstances, and I think we will get burnt by trying to go for the more theoretically pure approach now

[09:10:33.0000] <Hixie>
i really couldn't care less about theoretically pure, personally

[09:10:37.0000] <Hixie>
this is about authors

[09:10:45.0000] <Hixie>
and keeping the language sane and understandable for authors

[09:10:45.0000] <dglazkov>
I don't understand "theoretic" argument. It's what authors would expect

[09:10:50.0000] <dglazkov>
that's right

[09:11:27.0000] <jgraham>
They will expect that adding an <intent> tag will break their page in all old browsers?

[09:12:13.0000] <dglazkov>
there's a bit of a Stockholm-syndrome stuff happening here. Compatibility and don't-break-the-Web is one thing, but preferring to wallow in the mud just seems wrong.

[09:14:38.0000] <Hixie>
adding an <intent> tag will not "break their pages in all old browsers", that's complete hyperbole

[09:15:38.0000] <jgraham>
Shifting all the elements after the <intent> tag to a different place in the DOM seems highly likely to break the page

[09:18:13.0000] <Hixie>
i just went to opera.com, microsoft.com, and maps.google.com in opera, in each case i viewed the source and added an <intent> at the top of the page, and applied the changes. in no cases could i notice the slightest breakage.

[09:18:26.0000] <Hixie>
(except in maps where putting it before the doctype switched te quirks mode)

[09:18:57.0000] <Hixie>
(but moving it to the <head> fixed that)

[09:19:10.0000] <Hixie>
what page is it that is going to break?

[09:19:42.0000] <Hixie>
cnn.com also unaffected as far as i can tell

[09:19:50.0000] <Hixie>
(testing in opera)

[09:20:27.0000] <Hixie>
google login page also unaffected

[09:21:15.0000] <jgraham>
Sorry, I don't have time to look for examples now; I have to go (in general I would expect scripts to be more likely to break than other things)

[09:21:26.0000] <darobin>
<input> is definitely not a success story for authors

[09:21:40.0000] <darobin>
any DOM mangling inside forms is painful

[09:21:46.0000] <darobin>
not to mention styling

[09:21:46.0000] <Hixie>
plus.google.com did fall apart, i'll grant you that

[09:22:05.0000] <Hixie>
but in such a drastic way that it's hard to believe they wouldn't notice :-)

[09:23:13.0000] <Hixie>
youtube seems unaffected

[09:23:20.0000] <dglazkov>
Hixie: I think it's an interesting excursion that could be documented in a G+ post :)

[09:23:26.0000] <dglazkov>
so that we could refer to it later

[09:23:31.0000] <dglazkov>
hint hint

[09:24:14.0000] <Hixie>
twitter home page login screen unaffected

[09:24:36.0000] <Hixie>
twitter logged in home page unaffected

[09:24:53.0000] <Hixie>
what other pages could plausibly give intents?

[09:25:04.0000] <dglazkov>
flickr?

[09:25:10.0000] <dglazkov>
picnick?

[09:25:19.0000] <darobin>
pretty much any page, really :)

[09:25:29.0000] <Hixie>
definitely not any page

[09:25:38.0000] <darobin>
facebook

[09:25:43.0000] <Hixie>
(e.g. why would the second page of the html spec have an intent?)

[09:25:50.0000] <darobin>
definitely not all pages, but very arbitrary pages could

[09:26:05.0000] <Hixie>
google search results unaffected

[09:26:22.0000] <darobin>
the pick issues intent

[09:26:32.0000] <Hixie>
flickr seems unaffected

[09:26:54.0000] <Hixie>
flickr home page, i should say

[09:27:25.0000] <darobin>
linkedin

[09:27:57.0000] <darobin>
any calendar system

[09:28:19.0000] <Hixie>
flickr pic page also unaffected

[09:28:40.0000] <Hixie>
i thought it was broken at first but flickr's pic page these days is just ugly, it's unrelated to my adding <intent> :-P

[09:29:33.0000] <Hixie>
picnic seems to have been shut down

[09:30:04.0000] <Hixie>
i don't have a facebook login, but facebook's login page seems unaffected

[09:30:47.0000] <Hixie>
calendar.google.com seems unaffected

[09:31:13.0000] <Hixie>
linkedin's login page seems unaffcted

[09:31:50.0000] <othermaciej>
Hixie: the fact that <canvas> was a void element became a huge compat problem for us after others shipped it as non-void

[09:32:08.0000] <Hixie>
othermaciej: yeah, but that's the opposite problem. making it void in the first place didn't cause you problems.

[09:32:12.0000] <othermaciej>
Hixie: so I'm not sure that it's a good example of it being ok to add void elements

[09:32:23.0000] <Hixie>
live dom viewer unaffected

[09:32:23.0000] <othermaciej>
Hixie: well, the content authored assuming it was void broke in implementations where it was not

[09:32:28.0000] <othermaciej>
Hixie: in severe ways

[09:33:11.0000] <Hixie>
othermaciej: i agree 100% that we shouldn't go void then change to not-void unless there's a stunningly good reason (as there was with canvas)

[09:33:25.0000] <othermaciej>
Hixie: so the compat cost of having a difference is very high, and introducing a new void element creates at least a temporary transition time when there is a cross-browser difference

[09:33:57.0000] <Hixie>
so far the only page i've been able to break by adding an <intent> in the head is plus.google.com, and it broke so hard that it would be impossible for the team not to notice it and fix it.

[09:34:34.0000] <Hixie>
reddit unaffected

[09:34:48.0000] <Hixie>
i'm running out of sites to test here

[09:35:21.0000] <Hixie>
baidu search results unaffected

[09:36:05.0000] <Hixie>
maps.bing.com unaffected

[09:36:33.0000] <Hixie>
store.apple.com seems unaffected

[09:37:31.0000] <Hixie>
based on this research i remain unconvinced that there is a real compat risk

[09:37:35.0000] <Hixie>
or rather

[09:37:58.0000] <Hixie>
i remain unconvinced that the compat risk is higher than the value of the new element.

[09:38:23.0000] <Hixie>
(i agree that there's a risk and that there will be breakage, just not enough to justify a long-term wart)

[09:40:40.0000] <darobin>
+1, we jumped through the hoops trying to express <intent> with a bazillion other syntaxes and all of them just break down in usability rather quickly

[09:41:18.0000] <othermaciej>
so you know your change breaks at least one major site

[09:41:45.0000] <Hixie>
a site that would never ship the change without catching and fixing the problem

[10:15:37.0000] <AryehGregor>
othermaciej, <canvas> broke not because other browsers treated it as non-void, but because they treated it as non-void *and ignored the contents*, right?  Treating it as an unrecognized tag isn't a comparable failure mode.

[10:16:10.0000] <AryehGregor>
Hixie, but the methodology of your testing inherently excluded any sites that broke in not-totally-obvious ways, because you wouldn't have noticed them if it weren't totally obvious.

[10:16:30.0000] <AryehGregor>
So what you're really saying is that the only sites that broke in such obvious ways that you immediately noticed broke in such obvious ways that they would have been fixed before shipping.

[10:16:34.0000] <AryehGregor>
That's not a particularly compelling argument.

[10:16:42.0000] <othermaciej>
AryehGregor: I don't know if <canvas> is fully analogous to this case at all; I merely wanted to rebut the claim that it's an example showing it's ok to add void elements

[10:16:54.0000] <AryehGregor>
You'd have to make sure that all the page functionality worked.

[10:17:19.0000] <AryehGregor>
If Google+ breaks, that's a good PoC that some sites will break, subtly or not.

[10:17:40.0000] <AryehGregor>
I don't know if it's really such a problem, though, since it only affects UAs that *don't* implement the feature, and they can easily ship workarounds.

[10:18:56.0000] <AryehGregor>
othermaciej, well, that wasn't a case of *adding* a void element, it's a case of *changing* an element from void to non-void.  I think that's an entirely different situation from what's being discussed.  The processing of an *unrecognized* tag doesn't change much depending on whether it's void.

[10:19:49.0000] <AryehGregor>
Hixie, if you can persuade implementers, I say go ahead, but talk to the parser people at every browser and warn them that they should implement the parsing behavior ASAP even while they still process it as HTMLUnknownElement.

[10:19:49.0000] <othermaciej>
AryehGregor: Hixie is the one who cited <canvas> as a salient example

[10:20:38.0000] <AryehGregor>
Hixie, actually, one way to make the transition painless would be for browsers to deliberately support the parsing behavior for a while before they actually support the feature, so there's a window when authors will have no reason to bother using it (since it does nothing) but browsers won't break if they do.

[10:21:24.0000] <AryehGregor>
othermaciej, Hixie was talking about the initial support of <canvas> as a void element.  That didn't cause any compat problems, right?  It was the later change to a non-void element that caused the problems.

[10:22:28.0000] <othermaciej>
AryehGregor: I would say it was clearly the wrong choice to add it as void in retrospect, and that it wasn't non-problematic to do so

[10:22:43.0000] <othermaciej>
AryehGregor: it may have been a problem for totally different reason than <intent> could conceivably be

[10:22:58.0000] <othermaciej>
AryehGregor: but it's still not a good basis for arguing that it's fine to add void elements in general

[10:23:02.0000] <AryehGregor>
othermaciej, what problems did it cause to add it as void, other than the fact that it later deemed a good idea to make it non-void (which doesn't seem applicable here)?

[10:23:30.0000] <AryehGregor>
Well, if the argument is that new void elements in general are a problem, and <canvas> as a void element introduced no problems except ones that are clearly inapplicable to <intent>, I think it's fair to use it as an example.

[10:23:48.0000] <Hixie>
AryehGregor: certainly it's possible that i missed some stuff, but i did more than just look if the page seemed the same, i did try to use the page and test non-obvious things each time. this isn't my first barbecue. :-)

[10:24:07.0000] <othermaciej>
AryehGregor: I'm going to have to duck out of this discussion for now

[10:24:42.0000] <AryehGregor>
Hixie, you still didn't do anything that wouldn't have quickly shown up in even cursory testing.  Because you were still only doing cursory testing.  So disqualifying the Google+ breakage on the basis that it would have been caught by cursory testing still isn't sound.

[10:24:56.0000] <AryehGregor>
Really, we don't have to worry about sites like Google or Facebook, they'll do good enough testing.

[10:25:13.0000] <Hixie>
the Google+ breakage wouldn't have just been caught by cursory testing

[10:25:21.0000] <Hixie>
literally nothing rendered except a single triangle.

[10:26:06.0000] <AryehGregor>
GTG, but I think my point still stands.  I think this is doable with a suitable dose of caution -- particularly, making sure that everyone lands the parsing changes ASAP, preferably some way before the feature is actually supported by any browser.

[10:35:32.0000] <tantek>
I find it odd that there's so much focus on the discovery of intent providers (ala <intent> element) rather than the far greater number of publishers who want to put various web action like buttons on their sites (without writing / copy/pasting a heap of JS).

[10:36:26.0000] <tantek>
In my web actions talk at OSBridge in June, I discussed the straw proposal of an <action> element provide publisher functionality, that is to invoke an action like share, save, post, favorite, follow etc. on the page.

[10:37:44.0000] <tantek>
http://tantek.com/presentations/2012/06/osb12-web-actions/#slide15

[10:38:02.0000] <tantek>
start from the beginning if you want to see the context: http://tantek.com/presentations/2012/06/osb12-web-actions/

[10:38:12.0000] <Hixie>
there's been a couple of proposals, e.g. using <form>

[10:38:39.0000] <tantek>
anyway, I see no reason to standardize "intents" until the proponents, e.g. Google, actually fix their existing functionality (e.g. G+ buttons) to be more state of the art like Twitter.

[10:39:23.0000] <Hixie>
o_O

[10:39:25.0000] <tantek>
until then, intents strikes me as overly complex technology designed by folks who aren't even shipping modern markup work arounds

[10:40:00.0000] <tantek>
way beyond the average web author

[10:40:16.0000] <tantek>
whereas the average web author has no problems implementing simple Tweet actions links - which work even without JS

[10:40:21.0000] <tantek>
(unlike the G+ buttons)

[10:42:10.0000] <tantek>
btw Hixie, speaking of overly complex, I've kept going over the use-cases an examples for the autocomplete stuff and am having trouble proposing anything substantially simpler :/

[10:42:28.0000] <Hixie>
i hear ya

[10:42:30.0000] <Hixie>
i had the same problem

[10:42:37.0000] <tantek>
I may choose to take the path of not trying to match all the use-cases in preference for something simpler

[10:43:00.0000] <tantek>
that is, in basically saying, forget some of the whacky forms out there - those folks won't bother to update their markup with "autocomplete" attributes anyway

[10:43:17.0000] <Hixie>
unfortunately it's not clear that assumption is correct

[10:43:23.0000] <tantek>
I realize that involves making some judgment calls, but IIRC, you've in the past encouraged me to do so.

[10:43:44.0000] <tantek>
Hixie, usually inertia is a reasonable assumption :) (about people not updating their sites)

[10:43:47.0000] <Hixie>
oh, i absolutely agree that we have to make judgement calls about what to address and what not to address

[10:44:04.0000] <Hixie>
in this specific case, i think we're likely to see specific advocacy on adding those attributes

[10:44:08.0000] <tantek>
so I'm going to try to address a narrower subset to see if it generates a substantially simpler solution or not

[10:44:19.0000] <Hixie>
which makes it more likely that they'll get added

[10:44:27.0000] <Hixie>
especially if that advocacy comes with the promise of more sales

[10:44:30.0000] <Hixie>
which is plausible

[10:44:32.0000] <tantek>
sure, advocacy is something the a11y folks talk about too as a solution

[10:44:50.0000] <tantek>
that argument would also apply to fixing the forms themselves

[10:44:57.0000] <Hixie>
the accessibility folk can rarely point to concrete data showing improved conversion metrics in their advocacy :-)

[10:45:03.0000] <tantek>
so we if said, if you fix your forms and add these autocomplete attributes

[10:45:13.0000] <tantek>
that could work as well

[10:45:15.0000] <Hixie>
that typically also requires server-side changes

[10:45:32.0000] <tantek>
both do

[10:45:43.0000] <tantek>
though I think you mean data model / schema / database changes potentially

[10:45:51.0000] <tantek>
and yeah, that's a higher barrier, I agree

[10:46:03.0000] <Hixie>
right

[10:46:10.0000] <tantek>
anyway, just wanted to report back that I haven't been ignoring autocomplete, it's just been very frustrating :/

[10:46:22.0000] <Hixie>
roger

[10:47:11.0000] <tantek>
if I had to choose between putting a complex solution or wait for some simplification, I'd probably choose the latter.

[10:47:18.0000] <tantek>
(into the spec)

[10:47:33.0000] <tantek>
but I suppose it's worth documenting as a discussion point at least

[10:48:04.0000] <Hixie>
i think the choice is more between putting a medium-complexity solution in, and being forced to put it in an even more complex one later by virtue of a browser and some extensions shipping support for a more complex proposal :-)

[10:48:05.0000] <tantek>
the complex version in there now feels like pretty bad feature bloat

[10:48:39.0000] <Hixie>
if you think what's in there now is complex, you should have seen some of the other proposals... :_P

[10:48:41.0000] <tantek>
and lots of headaches for browser vendors trying to fix bad use of a complex solution

[10:48:50.0000] <tantek>
yeah - I realize there were many worse

[10:48:56.0000] <Hixie>
well, the spec has a pretty solid processing model, i think

[10:49:05.0000] <tantek>
I'd expect as much

[10:49:06.0000] <Hixie>
insofar as it can for something so inherently heuristic based

[10:49:17.0000] <tantek>
the challenge is whether any authors can understand it well enough to get it right

[10:50:02.0000] <tantek>
anyway, those are just high level thoughts, not real objections. I'll speak up again on this when I've got more specific/concrete suggestions.

[10:50:13.0000] <tantek>
sorry that this feedback is not particularly useful at this point.

[10:51:04.0000] <Hixie>
no worries

[10:51:17.0000] <Hixie>
it will be very interesting to see what authors do with it

[10:51:31.0000] <tantek>
but in terms of specific feedback, I'd be interested in what you thought of using a new <action> element to wrap existing service-specific web actions, e.g. very roughly:

[10:51:38.0000] <tantek>
<action do="post" with="permalink">

[10:51:39.0000] <tantek>
   <a href=twitter>..</a>

[10:51:40.0000] <Ms2ger>
/me leaves Hixie to fix bugs

[10:51:41.0000] <tantek>
   <a href=pinterest>...</a>

[10:51:41.0000] <tantek>
   ...

[10:51:42.0000] <tantek>
 </action>

[10:51:53.0000] <tantek>
no rush - just wanted to plant some more thoughts for consideration

[10:52:07.0000] <Hixie>
(i've been somewhat skeptical that anyone is going to use autocomplete, given the lack of success for past solutions, anyway. so it might end up entirely yanked at some point.)

[10:52:19.0000] <tantek>
for publishers who want to do both a generic web action, and have fallback to site-specific web actions

[10:52:27.0000] <tantek>
ah ok (re: autocomplete)

[10:53:02.0000] <Hixie>
tantek: for <action> i haven't studied the use cases enough to know what's needed and what's not

[10:53:07.0000] <tantek>
then I'll continue looking into simpler ways to markup such things - more from a copy/paste perspective (e.g. copy/pasting a whole contact, autocomplete is just a special case of that)

[10:53:20.0000] <Hixie>
tantek: (a lot of intents are actually a two-way conversation)

[10:53:32.0000] <tantek>
Hixie, hence <action> is just a rough sketch for now, based on existing publishing behaviors

[10:53:48.0000] <tantek>
the <a href> type actions, e.g. from Twitter, Pinterest, Foursquare etc.

[10:54:04.0000] <tantek>
(hopefully one day G+ will support <a href> actions instead of non-semantic JS-dependent <div> actions)

[10:54:17.0000] <Hixie>
it does seem like android has one action ("share") that is considered more important than others

[10:54:25.0000] <tantek>
Hixie, the simple intents that are actually in use on the web are mostly one-way conversations

[10:54:26.0000] <Hixie>
so maybe an <action> for that one intent makes sense

[10:54:37.0000] <tantek>
it might be a good starting point at least

[10:54:42.0000] <tantek>
and then we can iterate from there

[10:55:03.0000] <Hixie>
anyway, if you want this stuff considered, mail it on the thread :-) i don't have intents paged in right now

[10:55:09.0000] <tantek>
no problem

[10:55:25.0000] <Hixie>
/me has finally gotten around to dealing with bugs again, as Ms2ger noticed

[10:55:32.0000] <tantek>
I just saw the conversation above about it and was figuring I'd add a few opints.

[10:55:33.0000] <tantek>
points even.

[10:55:49.0000] <tantek>
/me wonders what an opint would be. a standard for Open Pints?

[10:57:45.0000] <hober>
iirc -o-pints are much more expensive than pints elsewhere in the world

[10:58:59.0000] <tantek>
hah

[10:59:12.0000] <astearns>
 it's a measure of how long it takes to state your opinion. a tweet is 1opint

[11:00:04.0000] <Hixie>
man, the spec sure regenerates a lot faster now that i don't have to regenerate the w3c copy as well each time

[11:02:42.0000] <dglazkov>
Hixie: баба с возу, кобыле легче

[11:03:58.0000] <Hixie>
dglazkov: not how i would have put it, but yes

[11:04:15.0000] <dglazkov>
:)

[11:04:59.0000] <dglazkov>
I am just happy to apply some Russian wisdom to any situation, however appropriate.

[11:05:36.0000] <dglazkov>
Actually, "I am just happy" is probably enough, too.

[11:05:39.0000] <Hixie>
i wish there was a reliable way, in chrome, of starting a find-in-page at a specific place in a document

[11:06:13.0000] <dglazkov>
there's a special magic place to turn wishes into fishes: http://new.crbug.com/ :P

[11:06:33.0000] <Hixie>
i've had very little luck getting wishes turned into fish there

[11:07:13.0000] <dglazkov>
:-\

[11:26:43.0000] <jamesr_>
dglazkov, "Woman with the cart, the mare is easier" ?

[11:28:40.0000] <dglazkov>
jamesr_: off the cart

[11:35:28.0000] <jgraham>
(fwiw the same kind of look-at-a-few-major-sites methodology would conclude that we didn't need the breaking-out-of-foreign-content-mode behaviour - which is hugely ugly and counterintuitive - because those huge sites don't typically have random <svg> tags in the source)

[11:38:02.0000] <jgraham>
(and if you think that frontend QA at Google or Facebook is good, I encourage you to look at https://github.com/operasoftware/browserjs/blob/master/desktop/browserjs-12.00.js )

[11:39:10.0000] <jgraham>
(yes, some of those are working around real bugs in Opera. That isn't the point)

[13:18:40.0000] <hoolter>
is there any way to alter what the numbers say in <ol>s? like instead of "1.", "2.", "3.", i want to have "Item 1.", "Item 2.", and "Item 3."?

[13:41:52.0000] <espadrine>
I don't understand why what TabAtkins suggests doesn't work in strict mode, in this mail: <http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0394.html> (it's the IndexedDB unprefixing thread)

[13:42:20.0000] <Ms2ger`>
indexedDB is a readonly attribute

[13:42:40.0000] <Ms2ger`>
That translates to a property without a setter

[13:42:50.0000] <Ms2ger`>
And in strict mode, assigning to such a property throws

[13:43:46.0000] <espadrine>
oh, readonly!

[13:43:55.0000] <espadrine>
ok, thanks!

[15:01:35.0000] <Hixie>
hoolter: in theory css lets you change it, dunno if anyone implements it

[15:19:03.0000] <hoolter>
Hixie: know how?

[15:19:39.0000] <gsnedders>
hoolter: Look up CSS counters

[15:20:31.0000] <hoolter>
gsnedders: are they widely implemented?

[15:20:50.0000] <gsnedders>
hoolter: Depends what you mean by widely. :)

[15:21:27.0000] <gsnedders>
They're in IE8 and everything else you'll care about.

[15:22:12.0000] <hoolter>
gsnedders: awesome! thanks :_

[15:22:12.0000] <hoolter>
)

[15:22:34.0000] <gsnedders>
Whether they work as expected on ol is a different question. :)

[15:23:39.0000] <hoolter>
gsnedders: why wouldn't they?

[15:24:36.0000] <gsnedders>
hoolter: You're assuming the numbering ol displays is implemented by CSS. :)

[15:25:23.0000] <hoolter>
gsnedders: i don't know what that sentence means.

[15:25:26.0000] <hoolter>
sorry :(

[15:25:48.0000] <gsnedders>
hoolter: ol shows numbering for the list.

[15:25:58.0000] <gsnedders>
That numbering may not be done using CSS.

[15:26:09.0000] <gsnedders>
If it is not, then you might not be able to override it using CSS.

[15:27:01.0000] <hoolter>
gsnedders: ah, i see.

[15:27:02.0000] <hoolter>
thanks.

[15:47:36.0000] <tobie>
jgraham: are you filing bug with us about those issues?

[15:49:45.0000] <gsnedders>
tobie: The ones which are patched through browser.js?

[15:50:13.0000] <gsnedders>
tobie: The ones that aren't Opera bugs have all been reported before being patched and gone unfixed for some period of time.

[15:50:23.0000] <gsnedders>
tobie: Some which are Opera bugs are never reported.

[15:52:28.0000] <Hixie>
well bummer

[15:52:37.0000] <Hixie>
per the spec, i think arguably <span><a></a></span> is non-conforming

[15:52:45.0000] <gsnedders>
wat.

[15:52:51.0000] <Hixie>
because the <a> doesn't contain phrasing content so it's not phrasing content...

[15:53:28.0000] <Hixie>
i wonder why <a> is only phrasing content when it contains phrasing content

[15:53:40.0000] <Hixie>
it doesn't need to be defined that way for the transparent content model thing to work

[15:55:13.0000] <tobie>
gsnedders: well LMK if there anything I can help with. I'm tobie⊙fc

[16:00:13.0000] <gsnedders>
tobie: In general most of our issues are down to conscious decisions not to support Opera, down to lack of marketshare, and a browser not supported by major sites won't get marketshare, etc.

[16:34:34.0000] <Hixie>
who should i cc on parser changes? jgraham, hsivonen, eseidel, abarth, anyone else?

[16:34:56.0000] <abarth>
fine with me

[16:35:05.0000] <abarth>
I can cc any other webkit folks as appriopriate


2012-08-10
[17:06:22.0000] <zewt>
gar why is it rel=noreferrer and not rel=noreferer, heh

[17:07:03.0000] <gsnedders>
:)

[17:07:23.0000] <zewt>
bad enough to have had to teach myself to type "referer" without now having it be 50/50

[17:27:18.0000] <TabAtkins>
zewt: Oh my lord, *seriously*?  That's the worst thing.  I mean, referer is evil for being misspelled, but we're not helping anyone by correcting it here.  >_<

[17:27:38.0000] <zewt>
webkit sends onclick to <input type=radio> after onchange?

[17:27:54.0000] <zewt>
that seems impossible enough to make me think I'm doing something stupid, heh

[17:28:04.0000] <jamesr_>
think of the children!

[17:28:28.0000] <jamesr_>
zewt, if you preventDefault() the onclick, does it go back in time and un-fire the onchange?

[17:28:36.0000] <zewt>
no black holes reported yet

[17:28:59.0000] <zewt>
i get the onchange first, with the checked value changed, then cancelling the onclick restores the old checked (without firing another onchange)

[17:29:05.0000] <jamesr_>
oh my god! it's gone plaid^Wopera!

[17:29:06.0000] <zewt>
(chrome, specifically)

[17:29:16.0000] <zewt>
i definitely feel like giving it the raspberry

[17:29:17.0000] <jamesr_>
zewt, that doesn't sound right

[17:29:21.0000] <zewt>
indeed

[17:29:27.0000] <jamesr_>
does it happen for any other checkbox-y types?

[17:30:00.0000] <zewt>
i'll check

[17:30:10.0000] <zewt>
(and put my test up for stupid-typo checking)

[17:30:43.0000] <jamesr_>
yeah and if you can file on bugs.webkit.org that'd be great

[17:33:10.0000] <zewt>
happens for checkbox too

[17:35:07.0000] <zewt>
https://zewt.org/~glenn/test-webkit-radio-click-cancel.html

[17:35:15.0000] <zewt>
logs very differently in chrome and FF

[17:36:04.0000] <zewt>
(... though it logs .checked == true in both, so maybe I'm doing at least something wrong)

[17:36:37.0000] <zewt>
(might just be .checked being the value it'd be after the click during onclick, which is weird but okay, but the event order is definitely being weird)

[17:57:07.0000] <benjoffe>
from reading the spec it looks like an 'output' element cannot have a 'list' attribute pointing to a datalist

[17:57:55.0000] <benjoffe>
this sound correct? if so it's a shame, cause there's what I think is a legitimate use-case for it

[18:02:20.0000] <hober>
what's the use case?

[18:16:51.0000] <zewt>
jamesr_: want to give that a quick sanity-check?

[18:17:48.0000] <jamesr_>
zewt, yeah looks legit

[18:17:54.0000] <zewt>
bizarre

[18:18:01.0000] <zewt>
seems like that should be breaking all kinds of things

[18:18:39.0000] <jamesr_>
maybe some of the common JS libraries have hacks around this area

[18:20:56.0000] <zewt>
what the hell

[18:21:19.0000] <zewt>
i download the webkit nightly in chrome, and it's putting up this big scary "WebKit-SVN-r125178.zip is not commonly downloaded and could be dangerous" nonsense

[18:28:52.0000] <benjoffe>
hober: if the output shall be textual, the one I'm thinking of is for a client side password strength measurer, the output can have values either 'Too short' 'Weak' 'Strong' etc.

[18:31:10.0000] <zewt>
(yeah I see why .checked is true during onclick in the spec)

[18:31:58.0000] <imakewebthings>
can anyone point me to a spec, if it exists, that says how a browser should restore scroll position on page reload? i'm specifically interested in what events should fire but anything would be good

[18:37:29.0000] <Hixie>
imakewebthings: http://whatwg.org/html is part of that loop

[18:39:14.0000] <zewt>
jamesr_: guessing this is intentional since IE does it too (ugh) suggesting webkit copied IE, but https://bugs.webkit.org/show_bug.cgi?id=93674

[18:39:40.0000] <zewt>
http://www.webkit.org/quality/reporting.html is "search bugzilla" supposed to be a joke? heh

[18:40:05.0000] <zewt>
did a couple searches which came back with 600 results, tried googling and like w3c it apparently blocks spiders, then gave up

[18:42:20.0000] <imakewebthings>
Hixie: Thanks, I suppose I should start digging in around 6.6.2 and see what I can determine from there

[19:23:52.0000] <Hixie>
imakewebthings: looks like it's at the bottom of the "update the session history with the new page" algorithm

[19:26:24.0000] <Hixie>
does anyone have an up to date implementation of the outline algorithm?

[20:17:46.0000] <imakewebthings>
Hixie: Thanks, I'm reading it as being left to user agents exactly what state to restore and how to go about it. The test case for why I ask: http://imakewebthings.com/sandbox/scroll-reload/

[20:18:47.0000] <Hixie>
too tired to understand that right now :-)

[20:19:03.0000] <Hixie>
if you want the spec changed, send e-mail and explain why it's important that every UA do the same thing

[20:29:49.0000] <imakewebthings>
no problem, thanks.

[23:26:03.0000] <jgraham>
tobie: Thanks. As gsnedders said we try to report bugs that end up being site-patched, but of course for huge sites having things break for even a short amount of time is bad, so I expect a few slip through the process

[00:36:12.0000] <Ms2ger>
Whoa

[00:37:40.0000] <Ms2ger>
http://www.whatwg.org/issues/data.html?period=1 < that was a lot of respimg emails

[00:54:46.0000] <jgraham>
Ms2ger: No, really?

[00:55:23.0000] <Ms2ger>
I blissfully ignored them :)

[00:57:05.0000] <jgraham>
"Estimated date for last e-mail based on the data above: 1999-08-08"

[00:57:34.0000] <jgraham>
(on the 3 years of data)

[04:02:34.0000] <krijn>
O hai, nobody is missing the logs huh? :)

[04:02:40.0000] <Ms2ger>
I am

[04:03:29.0000] <krijn>
The globbot thing looks handier

[04:04:03.0000] <Ms2ger>
It doesn't have highlighting

[04:04:07.0000] <krijn>
We've finally moved, so I need to setup my server in the new office thingy

[04:04:17.0000] <krijn>
Hopefully somewhere next week

[04:04:24.0000] <Ms2ger>
Great :)

[04:06:01.0000] <Ms2ger>
odinho, fwiw, I'm having someone write tests for blob.slice

[04:06:54.0000] <odinho>
Ms2ger: yay someone

[04:09:31.0000] <Stevef_>
krijn: i have been missing them!

[04:09:55.0000] <krijn>
They will be up again! :)

[04:10:26.0000] <krijn>
If I can't get my server up and running again, I'll point my site to a different one and make a static copy

[04:12:12.0000] <Ms2ger>
odinho, also, can has a build with constructor support? :)

[04:15:53.0000] <odinho>
Ms2ger: Maybe I can just send you my binary here-here? :P

[04:16:03.0000] <Ms2ger>
Sure :)

[04:22:37.0000] <odinho>
Ms2ger: Ah, it's in ci-337, so desktop have it in the 12.50 build. Crazy-old, but there's a huge gap between desktop 12 and "us".

[04:24:09.0000] <Ms2ger>
12.50 internal / build 1497 doesn't seem to have it

[04:25:36.0000] <odinho>
http://snapshot.opera.com/unix/looooooooooong_12.50-1538/ << 1538 seems to be the number

[04:25:53.0000] <odinho>
wtf up with looooooooong

[04:26:22.0000] <darobin>
maybe it supports longdesc?

[04:26:53.0000] <odinho>
yeah, the ultimate marketable feature ;D

[04:27:33.0000] <darobin>
since when has Opera been about marketable features?

[04:28:11.0000] <odinho>
If we put it in the url it has to be very important, does it not?

[04:29:05.0000] <darobin>
nah, we all know URLs are opaque and all

[04:29:26.0000] <odinho>
Guess G+ taught us that

[04:29:33.0000] <darobin>
heh

[04:50:43.0000] <MikeSmith>
wow krijn is alive

[04:50:55.0000] <krijn>
Of course!

[04:51:21.0000] <MikeSmith>
krijn: I thought you had retired to the cote d'azur, like Batman

[04:53:12.0000] <krijn>
Actually I did

[04:53:12.0000] <Ms2ger>
odinho, quite some test failures, still :)

[04:53:21.0000] <krijn>
Thought nobody noticed

[04:53:24.0000] <MikeSmith>
heh

[04:53:38.0000] <MikeSmith>
I'm glad you decided to come back and fight more crime

[04:53:52.0000] <odinho>
Ms2ger: (whisper)we have a bug called "fix ms2gers' blob test failures"

[04:54:01.0000] <Ms2ger>
:)

[04:54:45.0000] <odinho>
But blob guy is on a long deserved vacation.

[04:55:12.0000] <krijn>
http://krijn.qontent.nl/server.jpg should have some vacation as well

[04:55:35.0000] <odinho>
krijn: lol, 1995 called, it wants its computer back.

[04:55:59.0000] <krijn>
(Note says: "Do not turn off, the internet relies on this machine! Even though no monitor or keyboard is attached, this thing is working!")

[04:56:17.0000] <MikeSmith>
krijn: that explains things. you're powering it from your radiator

[04:56:23.0000] <krijn>
I'm glad they ignored the note

[04:56:37.0000] <MikeSmith>
krijn, btw, I will be in Amsterdam next month for a few days. Planning to meet up with Anne and whoever feels like getting together for foods and beers or whatnot

[04:56:45.0000] <krijn>
odinho: :p

[04:56:55.0000] <krijn>
MikeSmith: oh! when?

[04:57:06.0000] <MikeSmith>
around 13-14-15 I think

[04:57:20.0000] <jgraham>
/me always assumed that the logs were running on a souped-up toaster

[04:57:26.0000] <krijn>
I'll be in Amsterdam then as well

[04:57:42.0000] <MikeSmith>
cool

[04:57:45.0000] <krijn>
MikeSmith: if Anne allows me to join, I'd be happy to :)

[04:57:56.0000] <MikeSmith>
I'll talk to him once he's back

[05:00:54.0000] <niloy>
Why isnt any other browser implementing setImmediate?

[05:01:23.0000] <krijn>
MikeSmith: oki, cool, ping me when you know more :)

[05:01:28.0000] <krijn>
<-- gone now o/

[05:01:30.0000] <Ms2ger>
Is that Microsoft's thing?

[05:01:36.0000] <niloy>
yes

[05:01:49.0000] <jgraham>
Isn't that the thing that's precisely the same as setTimeout(f, 0)

[05:02:06.0000] <niloy>
yes, so is setTimeout the recommended thing?

[05:02:11.0000] <Ms2ger>
It was a silly thing, that much I recall

[05:02:55.0000] <niloy>
so does the browser automatically treat setTImeout(f, 0) to be executed in the next  event loop?

[05:03:38.0000] <jgraham>
Well I suppose it doesn't force it to the front of the event queue

[05:03:58.0000] <jgraham>
But if setImmediate is supposed to do that it seems very wrong

[05:04:09.0000] <niloy>
nodeJS has nextTict(), the browser needs something like that too

[05:04:27.0000] <jgraham>
e.g. setImmediate(f1); setImmediate(f2) would lead to f2 being run before f1

[05:04:28.0000] <niloy>
s/nextTict/nextTick/

[05:04:31.0000] <Ms2ger>
Huh

[05:04:54.0000] <Ms2ger>
Opera seems to restore tabs when hitting ctrl+w

[05:04:58.0000] <Ms2ger>
Is that intentional?

[05:05:05.0000] <niloy>
nodeJS has nextTick which accepts a callback which gets executed in the next event loop

[05:06:15.0000] <jgraham>
It has the behaviour I said above?

[05:07:01.0000] <niloy>
Umm... am not sure about that, but will it break something horribly?

[05:07:22.0000] <Ms2ger>
Sounds like a good way to hang your browser

[05:07:49.0000] <niloy>
how so? 2 events will be executed one after another right?

[05:08:12.0000] <niloy>
but you guys know better, so I will take your word on it

[05:08:44.0000] <jgraham>
niloy: In a browser, not processing e.g. user input events is bad

[05:08:59.0000] <jgraham>
node.js doesn't really have that problem

[05:09:48.0000] <jgraham>
So if people start running code that jumped the event queue it could lead to badness

[05:10:13.0000] <jgraham>
IOW setTimeout(f, 0) seems like a better idea in a browser

[05:13:14.0000] <niloy>
alright, thanks

[05:14:39.0000] <smaug____>
requestAnimationFrame(f) is possibly even better than setTimeout(f, 0)

[05:15:15.0000] <smaug____>
depending on what you're going

[05:15:18.0000] <smaug____>
er

[05:15:20.0000] <smaug____>
doing

[05:17:28.0000] <jgraham>
Yes, if you need to sync with painting

[05:27:29.0000] <niloy>
I am attaching around 1000 nodes to DOM which is freezing the UI

[05:28:14.0000] <jgraham>
Testcase?

[05:30:04.0000] <niloy>
umm, I dont have it prepared, its happening with the application I am developing at my job

[05:30:49.0000] <niloy>
but I guess I can make something quick on jsfiddle

[05:30:57.0000] <jgraham>
Well if you can provide a simple TC that reproduces the behaviour, it will be easy to help. If you can't it won't :)

[05:31:23.0000] <jgraham>
(fwiw the Live DOM viewer is preferred comnpared to js-fiddle in these parts)

[05:31:30.0000] <jgraham>
(because it is simpler)

[05:32:08.0000] <niloy>
/me is embarrased, doesnt know what Live DOM viewer is

[05:32:46.0000] <jgraham>
It's OK, I was just looking up the URL

[05:32:48.0000] <jgraham>
http://software.hixie.ch/utilities/js/live-dom-viewer/

[05:32:52.0000] <niloy>
thanks

[05:33:12.0000] <jgraham>
It's not really popular in the wider web community, but it has a helpful level of simplicity

[05:33:28.0000] <niloy>
cool, I will check it out

[05:33:30.0000] <jgraham>
For example it doesn't encourage the use of jQuery-for-everything

[05:33:37.0000] <niloy>
hehe

[05:34:18.0000] <jgraham>
(10 line testcases with 10,000 lines of library code are 10,010 line testcases ;)

[05:34:34.0000] <niloy>
:)

[05:36:27.0000] <niloy>
jgraham, umm... where do I write JS?

[05:36:46.0000] <Ms2ger>
<script>// JS</script>

[05:36:54.0000] <niloy>
okay, thanks

[05:44:47.0000] <niloy>
I tried creating 1000 divs, it happened quiet instantly

[05:45:04.0000] <darobin>
niloy: FWIW one way of getting something rather close to nextTick is to use postMessage

[05:45:40.0000] <niloy>
I should postMessage to window?

[05:45:42.0000] <darobin>
setTimeout has a minimal delay that the browser enforces, postMessage doesn't (yet)

[05:45:53.0000] <darobin>
yeah, you postMessage to yourself, comes with the next event loop

[05:46:03.0000] <niloy>
Oh, thats great

[05:46:15.0000] <niloy>
thank you

[05:46:28.0000] <darobin>
at least, that used to work, it may now be defended against — let me dig it up

[05:46:34.0000] <darobin>
here http://dbaron.org/log/20100309-faster-timeouts

[05:47:08.0000] <niloy>
I am creating a tree component, so before every node inserting, I am perform some tree traversing

[05:47:23.0000] <niloy>
so the UI hangs even with 1000 nodes

[05:47:45.0000] <niloy>
I am not able to replicate with a simple for loop with 1000 div insertion

[05:47:45.0000] <darobin>
niloy: here's an example https://github.com/substack/node-browserify/blob/master/builtins/__browserify_process.js

[05:48:04.0000] <niloy>
darobin, thanks a lot

[05:48:19.0000] <darobin>
np

[05:49:15.0000] <jgraham>
In theory setTimeout only has a delay when called recursively

[05:49:42.0000] <darobin>
jgraham: I think it has a delay when you call it in a loop, no?

[05:49:53.0000] <darobin>
but recursively would be a problem here anyway

[05:50:30.0000] <jgraham>
Only recursively in the spec

[05:50:56.0000] <niloy>
I am currently calling setTimeout recursively, its solved the UI freeze problem

[05:51:13.0000] <niloy>
in each setTimeout call, I insert 1 node

[05:51:39.0000] <niloy>
and then call setTimeout again till I reach the end of array

[05:52:03.0000] <niloy>
It has fixed the UI freeze problem, but it feels very hackish

[05:52:25.0000] <darobin>
niloy: no, sometimes you have to do things like that to handle large numbers of synchronous ops

[05:52:29.0000] <darobin>
it's part of the platform

[05:52:50.0000] <darobin>
Node spoils you by enforcing it a lot of the time

[05:52:55.0000] <darobin>
but it's still what it does

[05:53:24.0000] <darobin>
if it feels too hackish, just hide it in a library ;-)

[05:53:44.0000] <niloy>
darobin, no no, dont get me wrong

[05:53:48.0000] <darobin>
actually I think that's what async.js does when in the browser

[05:54:25.0000] <niloy>
I just wish the browser would provide something a api natively, like setImmediate

[05:55:24.0000] <niloy>
I mean, technically animations can be done by setTimeout, but the browers came with requestAnimationFrame, which is amazing

[05:56:16.0000] <niloy>
so I was just wish browsers would give us something so execute stuff in a async manner without any minimum delay

[05:57:16.0000] <darobin>
niloy: yeah, I think that makes sense

[05:57:24.0000] <niloy>
thanks ^_^

[05:57:38.0000] <darobin>
"execute this as soon as possible, async (but you're allowed to prioritise something else if it makes more sense)"

[05:57:47.0000] <darobin>
I haven't looked at setImmediate tbh

[05:57:53.0000] <niloy>
yes, exactly ^_^

[05:58:38.0000] <darobin>
maybe we could get there if setTimeout can be implemented in a more helpful fashion though (I haven't thought this through at all atm)

[05:59:43.0000] <niloy>
yeh, if browers remove minimum delay from setTimeout, that would become equivalent, but I guess it has technical issues

[06:00:08.0000] <niloy>
since I am not a browser developer, I dont know :(

[06:00:36.0000] <darobin>
niloy: sometimes you don't want to let JS code just flood the event loop; it wouldn't work out

[06:01:14.0000] <darobin>
but one probably *could* resort to smarter mechanisms than just a delay

[06:01:32.0000] <niloy>
yeh

[06:51:40.0000] <AryehGregor>
Hmm, does Google+ translate "  " into " &nbsp;"?  It should be "&nbsp; " -- the way they have it now adds whitespace at the beginning of lines.

[06:52:47.0000] <AryehGregor>
/me sends feedback

[08:41:47.0000] <dglazkov>
good morning, Whatwg!

[08:45:28.0000] <tantek>
good morning dglazkov

[10:11:56.0000] <Hixie>
jesus, the linked data folk are now trying to get RDF into HTML through the back door with JSON-LD

[10:15:23.0000] <hober>
and you're surprised?

[10:17:07.0000] <Hixie>
their persistence is admirable

[10:17:47.0000] <Hixie>
also, julian is lying in ietf-types again to get his pet ideas through, sigh

[10:29:10.0000] <Hixie>
hey can anyone think of technologies that have tried to replace HTML recently other than .NET and XHTML2?

[10:29:13.0000] <Hixie>
i'm having a mind blank

[10:30:16.0000] <TabAtkins>
How recently? Flash and Silverlight made attempts.

[10:30:26.0000] <jarek>
uhm... Adobe Air

[10:30:57.0000] <jarek>
it was sort of a compromise between Flash and HTML

[10:30:59.0000] <Hixie>
ah yes, Flash and Air

[10:31:03.0000] <Hixie>
(Silverlight is .NET)

[10:31:43.0000] <jarek>
and JavaFX

[10:32:38.0000] <Hixie>
ah yes, of course, how could i forget java

[10:45:09.0000] <jgraham>
And native apps :)

[11:15:23.0000] <bfrohs>
If an document contains <input autofocus> and a textarea is added later via JavaScript with the autofocus attribute, which element should be focused? Chrome focuses the textarea while Firefox focuses the input.

[11:16:14.0000] <bfrohs>
To test: data:text/html,<!DOCTYPE html><form><input autofocus><script>el = document.createElement("textarea");el.setAttribute("autofocus", "");document.body.appendChild(el);</script></form>

[11:16:14.0000] <Hixie>
bfrohs: see the spec :-)

[11:16:43.0000] <Hixie>
( http://www.whatwg.org/specs/web-apps/current-work/#autofocusing-a-form-control:-the-autofocus-attribute )

[11:16:54.0000] <bfrohs>
Hixie: Yes, I'm there.

[11:17:15.0000] <bfrohs>
My thoughts are it should be the input, as #7 aborts the steps. Am I correct?

[11:18:19.0000] <Hixie>
yes

[11:18:45.0000] <bfrohs>
Thanks much! :)

[11:28:10.0000] <sawrubh>
is the HT(horizontal tab) mentioned in http://tools.ietf.org/html/rfc2616#page-16 8 or 4 spaces ?

[11:28:49.0000] <TabAtkins>
It appears to be a tab character. U+0009.

[11:29:41.0000] <sawrubh>
so what is that, 4 or 8 spaces, I need to use it in a token

[11:29:57.0000] <TabAtkins>
It's neither.  It's a *tab character*.  That's a different thing than a space.

[12:17:57.0000] <zewt>
was text-outline a thing that disappeared? it's something webvtt would want pretty badly (and seems to think still exists, since it's mentioned as a supported style)

[12:19:26.0000] <zewt>
can sort of fake it with text-shadow, but ... badly

[12:19:39.0000] <zewt>
particularly with serif fonts

[12:28:28.0000] <Hixie>
zewt: it's in some css spec or other

[12:30:49.0000] <zewt>
it's in http://www.w3.org/TR/2007/WD-css3-text-20070306/ but not the current ED, if it's moved somewhere else I havn't found it

[12:44:08.0000] <Hixie>
wtf opera

[12:44:19.0000] <Hixie>
'cellIndex' in document.createElement("th") => true

[12:44:26.0000] <Hixie>
document.createElement("th").cellIndex => undefined

[12:44:37.0000] <Hixie>
how is that even possible

[12:44:49.0000] <tantek>
maybe it depends on which site you're pretending to be?

[12:44:53.0000] <tantek>
some per-site quirkiness?

[12:44:58.0000] <gavinc>
property exists, has no value?

[12:45:25.0000] <Hixie>
if the property exists, the getter should return a value of the property's type

[12:45:37.0000] <Hixie>
i don't understand how you even write code that can end up with the getter returning undefined

[12:45:46.0000] <Hixie>
i mean, you have to actually work to do that, as far as i can tell

[12:46:02.0000] <Hixie>
given that C++ doesn't have "undefined" as a value for "long"

[12:46:11.0000] <Ms2ger>
Ah, you got there :)

[12:46:23.0000] <Ms2ger>
Apparently Opera doesn't do dom bindings

[12:46:44.0000] <Hixie>
Ms2ger: thanks for the test case and results, btw, makes my life WAY easier

[12:47:04.0000] <Ms2ger>
I try :)

[12:47:36.0000] <Hixie>
i haven't tested IE for myself

[12:47:43.0000] <Hixie>
i'm scared to given what you reported as the result

[12:47:47.0000] <Hixie>
("semi-random numbers")

[12:48:02.0000] <Ms2ger>
It might be that's only IE10

[12:48:31.0000] <Ms2ger>
And I have no idea if there is any newer IE10 snapshot than the one that I managed to get my hands on somehow

[12:48:48.0000] <Hixie>
testing on IE is a huge pain for me (have to spin up a vm in a faraway cluster, etc)

[12:49:02.0000] <Hixie>
but anyway, doesn't matter here

[12:49:07.0000] <Hixie>
since there's clearly no interop!

[12:49:30.0000] <Ms2ger>
If only they released IE for Linux...

[12:49:44.0000] <Ms2ger>
For the long ignored spec editors' market

[12:50:11.0000] <Hixie>
actually i'm on mac currently

[12:50:26.0000] <Ms2ger>
IE5.5 for mac, then? :)

[12:50:41.0000] <Hixie>
probably not useful :-P

[12:53:01.0000] <Ms2ger>
/me files on other browsers

[13:08:42.0000] <Yuhong>
I am thinking of a protocol on top of WebSockets that with the user's permission, allow to read and write files on the user's hard drive.

[13:09:25.0000] <Yuhong>
The idea is that the browser would allow the user to select files just like a file upload, but instead of uploading the file, return a token.

[13:09:47.0000] <Yuhong>
That can be later used to tell the browser to read or write the file.

[13:10:20.0000] <zewt>
... File?

[13:10:41.0000] <Yuhong>
What do you mean?

[13:11:07.0000] <Yuhong>
The idea to allow a Google Docs like to be created that do not store the files on the server.

[13:11:31.0000] <zewt>
file api gives a token (File) to read files (and filesystem API allows writing files, though that's moving slowly)

[13:11:45.0000] <zewt>
(not sure what WebSockets has to do with files)

[13:12:59.0000] <Yuhong>
Did not realize such an API already exist.

[13:13:08.0000] <Yuhong>
Did not realize such an API already exist.

[13:15:07.0000] <Ms2ger>
Bye

[13:15:13.0000] <zewt>
ragequit?

[13:15:19.0000] <zewt>
"relax, have some dip"

[13:15:38.0000] <Ms2ger>
It's an interesting figure, I have to admit

[13:15:56.0000] <Yuhong>
Ms2ger: Win8 just RTMed.

[13:16:03.0000] <Ms2ger>
I see

[13:16:09.0000] <zewt>
does that mean "crashed"

[13:16:24.0000] <Yuhong>
Release to Manufacturing.

[13:17:17.0000] <Yuhong>
It will behttp://arstechnica.com/information-technology/2012/08/windows-8-released-to-manufacturing-with-build-9200/

[13:17:22.0000] <Yuhong>
http://arstechnica.com/information-technology/2012/08/windows-8-released-to-manufacturing-with-build-9200/

[13:17:38.0000] <Yuhong>
Has the key dates for when you will be able to get it.

[13:17:50.0000] <zewt>
does anybody not hate win8? heh

[13:18:11.0000] <zewt>
it's like they went "well, people liked XP, hated Vista, liked win7, so it's time to do something horrible again!"

[13:23:06.0000] <Yuhong>
Found the File API, thank you.

[13:24:55.0000] <Yuhong>
And File API: Writer.

[13:41:21.0000] <zewt>
when did google decide it was okay to just ignore search terms entirely, thus becoming worthless

[13:42:26.0000] <zewt>
haha http://wiki.whatwg.org/wiki/Timed_tracks#Architecture i wonder who made this illustration and thought, "there, that clarifies everything!"

[14:06:23.0000] <Hixie>
zewt: that was me, but iirc it wasn't intended to clarify things but more to illustrate what a mess it was :-)

[14:26:22.0000] <smaug____>
what does chromium bug status Icebox mean?

[14:27:06.0000] <smaug____>
/me noticed a valid bug he had filed long ago got that status

[14:28:56.0000] <jgraham>
Hixie: Looks like a rather straighforward bug.

[14:42:36.0000] <jamesr_>
smaug____, it's a bot

[14:42:42.0000] <jamesr_>
smaug____, if it did something bad link me the bug and i can fix it

[14:44:13.0000] <smaug____>
jamesr_: http://code.google.com/p/chromium/issues/detail?id=75770 I don't have chromium to verify if that is still valid

[14:44:50.0000] <smaug____>
oh, and the test might need update to not report the very last progress event

[14:51:20.0000] <zewt>
bleh I hate hitting obvious bugs that every browser has, because hope of getting them fixed drops through the floor

[14:51:39.0000] <zewt>
re: cancelling mousedown preventing mouse thresholding from being applied to clicks (in IE, WebKit *and* Firefox)

[14:52:52.0000] <zewt>
(not opera)

[15:02:59.0000] <zewt>
Hixie: at least it's not a flowchart :)

[15:08:43.0000] <Hixie>
jgraham: sure, it's just the implications regarding the infrastructure that i am worried about :-)

[15:30:38.0000] <TabAtkins>
Hixie: In the CSS that establishes quoting, what's the reasoning for doing ":root:lang(X), :not(:lang(X)) > :lang(X)"?  It seems like this is equivalent to just writing ":lang(X)".

[15:32:14.0000] <TabAtkins>
Possible answer: it avoids overriding author's rules placed somewhere in the middle of a tree of same-lang elements.

[15:35:59.0000] <TabAtkins>
Hixie: Actually, that's almost certainly the correct answer.  So never mind the question, I answered it myself.

[16:13:14.0000] <jamesr_>
smaug____, i can't tell that chrome's behavior is non-conformant here (because the spec text is super fuzzy)

[16:13:27.0000] <jamesr_>
what does "about every 50ms" mean?

[16:14:38.0000] <jamesr_>
is it supposed to fire progress even if no bytes were transmitted?

[16:15:15.0000] <smaug____>
jamesr_: nope. when I filed that bug chrome was firing events way more often than that

[16:15:31.0000] <smaug____>
events shouldn't happen more often that 50ms

[16:15:39.0000] <smaug____>
except the last one right before loadend

[16:15:59.0000] <smaug____>
s/often that/often than every/

[16:18:22.0000] <jamesr_>
more often than "about 50ms"

[16:18:31.0000] <jamesr_>
what's the rationale for that limitation?

[16:18:49.0000] <smaug____>
to not fire event like every ms

[16:18:50.0000] <jamesr_>
i'd guess naively that it's firing based on feedback from the network stack

[16:19:13.0000] <smaug____>
yeah, gecko used to have that behavior too

[16:19:31.0000] <jamesr_>
and what platform are you testing on?

[16:19:59.0000] <smaug____>
that is an old bug :)

[16:20:00.0000] <jamesr_>
i'm getting 50/51 on your test page on 22.0.1221.1 linux

[16:20:07.0000] <smaug____>
ok, if you get that, then ok

[16:20:13.0000] <smaug____>
perhaps it is then fixed

[16:20:28.0000] <jamesr_>
i think we fixed it: http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/xml/XMLHttpRequestProgressEventThrottle.h&exact_package=chromium&q=xmlhttprequest%2050&ct=rc&cd=4&sq=

[16:20:52.0000] <smaug____>
k

[16:20:55.0000] <smaug____>
thanks then :)

[16:21:23.0000] <smaug____>
(the bug should be marked then fixed)

[16:21:29.0000] <jamesr_>
yup, did that

[16:21:59.0000] <smaug____>
/me doesn't have chromium installed because it is always so hard to find the nightly .zip files

[16:22:25.0000] <jamesr_>
what platform are ya on? on windows/mac the canary channel is easy

[16:23:01.0000] <smaug____>
linux

[16:23:31.0000] <jamesr_>
i use dev channel normally (of course i normally have a fresh ToT build i produced myself)

[16:23:38.0000] <jamesr_>
dev's ~weekly which is not too bad

[16:24:09.0000] <smaug____>
I just never find the .zip file when I try to find it

[16:24:38.0000] <smaug____>
and once I find it, I end up using the same build for weeks or months because I forgot where I downloaded it :)

[16:24:46.0000] <smaug____>
(and because the .zip doesn't auto-update)

[16:25:20.0000] <jamesr_>
it's linux man, just use the .deb

[16:25:52.0000] <smaug____>
well, not .zip, but tar.gz or whatever

[16:25:59.0000] <smaug____>
just simple package

[16:26:06.0000] <smaug____>
which I can unpack

[16:26:22.0000] <smaug____>
though, I think it is .zip in chromium case

[16:26:47.0000] <jamesr_>
sure, but why?

[16:27:11.0000] <smaug____>
last time I used .rpm or some such, it polluted my update process

[16:27:25.0000] <smaug____>
I don't want to get notified when there is update to chromium

[16:28:01.0000] <jamesr_>
it's kinda broken to get notified about any package update, it should just install

[16:28:21.0000] <zewt>
heh firefox is trying to copy chrome's autoupdate, but still does it badly

[16:28:25.0000] <smaug____>
possibly I'm just too used to Firefox nightlies

[16:28:42.0000] <zewt>
re: middle of development, i load firefox to test, and it stops for fifteen seconds with an "installing update" while I sit there losing my train of thought

[16:29:02.0000] <smaug____>
zewt: on linux Firefox's autoupdate is way nicer

[16:29:18.0000] <smaug____>
than chromiums

[16:29:58.0000] <zewt>
i never notice chrome's updating in windows, which is the only possible way autoupdate is okay

[16:30:31.0000] <smaug____>
that is the Firefox update works on linux, and should work on windows too

[16:32:28.0000] <jamesr_>
it's a bit ironic that out of win/mac/linux, linux is the system with the oldest and most deeply integrated system update mechanism

[16:32:35.0000] <jamesr_>
but it's the worst updating experience of any chromium

[16:32:39.0000] <jamesr_>
or chrome, rather

[16:33:00.0000] <zewt>
heh, linux *had* to, since binary compatibility is so bad in linux

[16:33:15.0000] <jamesr_>
YOTLD

[16:33:16.0000] <zewt>
so distributing prebuilt packages is a massive pain

[16:33:59.0000] <jamesr_>
for instance i'll wager if if major distros ever actually do the gtk2->gtk3 switch, a lot of apps will statically link gtk2 in

[16:34:25.0000] <zewt>
i've always had to save VMs of linux build systems for building binary patches later, since otherwise it's often a complete nightmare of working around library, runtime linker, etc. incompatibilities

[16:34:48.0000] <zewt>
and this is on systems where i controlled the whole target system

[16:35:26.0000] <zewt>
vs. windows where you can run most stuff built for win95 in win7, heh

[16:37:23.0000] <zewt>
(granted not necesarily the reverse)


2012-08-11
[17:17:26.0000] <gsnedders>
Anyone know of an HTML parser in Erlang?

[19:55:12.0000] <zewt>
a little silly that to do window.location.href = url with rel=noreferrer, apparently you have to create a dummy A and call .click(), heh ... wonder if there's any less silly way, though I guess that works

[19:55:34.0000] <Hixie>
use an <a href=""> link? :-)

[20:03:38.0000] <Hixie>
TabAtkins: yeah. i was trying to make it work like a presentational attributes, basically.

[20:17:10.0000] <zewt>
it's programmatic, not a link, heh

[20:55:05.0000] <zewt>
heh, 3d transitions are nice on mobile safari for smoothness, but ... buggy as hell

[21:00:30.0000] <zewt>
transitions of 3d transforms, that is

[21:01:44.0000] <zewt>
heh, like opacity: 0 layers on top being visible as if they're opacity: 0.01

[21:18:40.0000] <zewt>
maybe it's just chrome, it seems to work fine in mobile safari; guess i'll dig into it more tomorrow

[22:00:09.0000] <zewt>
borderline shocked that people can seriously, with a straight face, argue that black backgrounds behind subtitles is even conceivably a better default than a stroked font

[22:13:08.0000] <zewt>
sometimes i feel like if I suggest going out for steak, i'll have to fight tooth and nail with people who insist that the pile of nails and broken glass is a perfectly decent meal

[22:40:25.0000] <Hixie>
zewt: it's happening after the user clicks something right?

[22:52:30.0000] <zewt>
Hixie: yes, but as a result of JS logic a couple layers deep

[01:00:34.0000] <Ms2ger>
/me pokes Velmont 

[02:17:16.0000] <Stevef_>
zewt: re "black backgrounds behind subtitles" recommendations from NAD (US) is "Characters must be sans serif, have a drop or rim shadow, and be proportionally spaced. " a translucent box is preferred so that the text will be clearer, especially on light backgrounds." http://www.dcmp.org/captioningkey/text.html

[07:56:21.0000] <karlcow>
"If you analyze XML sent as text/html on the web, something like 95% of it is invalid XML, for lots of different reasons." — http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-August/036873.html not sure I understand this by tabatkins

[07:57:49.0000] <karlcow>
or does he mean documents written with XML syntax rules, sent as text/html and being not well-formed.

[08:07:13.0000] <Ms2ger>
Breaking news, HTML is not XML?

[08:17:57.0000] <karlcow>
☺ heh

[09:33:31.0000] <Hixie>
zewt: do the logic early, and just have a link :-)

[09:37:03.0000] <zewt>
Hixie: always keeping a DOM node in sync with script state changes is much more brittle

[09:37:37.0000] <zewt>
less hacky to just do the createElement/click workaround :)

[09:44:25.0000] <Hixie>
zewt: why is it brittle?

[09:44:46.0000] <Hixie>
zewt: how else would you make it possible for the user to copy link location, open link in new tab, drag the link, bookmark the link, etc?

[09:48:35.0000] <zewt>
it's a link to an oauth login flow (or not, depending on the situation) that responds back to a script on the calling site; not even sure what would happen if it was launched in some other way

[09:53:32.0000] <Hixie>
heh

[09:53:54.0000] <Hixie>
why noreferrer?

[09:57:29.0000] <zewt>
paranoia :) it's a site used soley for user authentication, and while there should never be anything sensitive to leak in the URL, this is the only place the site loads anything external

[15:48:17.0000] <zewt>
cool, havn't seen the "people don't abuse this in native apps so what's the problem" argument in a while


2012-08-12
[17:08:48.0000] <adlwalrus>
is this valid for an iframe? <!doctype html> <img onload="window.parent.postMessage('VIRGIN_VISIT', '*');"	src="http://assangedefenseleague.allalla.com/virgin_detect.php" />

[17:10:06.0000] <weinig>
adlwalrus: valid in what sense?

[17:10:47.0000] <adlwalrus>
weinig: in the html specification one?

[17:11:01.0000] <adlwalrus>
i mean, it wasn't rendering for some reason but i couldn't see anything wrong with it.

[17:11:05.0000] <adlwalrus>
iframes don't need titles

[17:11:14.0000] <adlwalrus>
then it magically started working.

[17:11:20.0000] <adlwalrus>
so i don't have a problem anymore.

[17:11:26.0000] <adlwalrus>
but i'd still be curious.

[17:11:41.0000] <weinig>
it should fine

[17:12:03.0000] <weinig>
that said, it has no visible content, since it seems like the image is just a 5x5 blank image

[17:12:26.0000] <weinig>
the trailing / is also not doing anything good

[17:40:56.0000] <adlwalrus>
weinig: thanks.

[20:56:46.0000] <zewt>
bleh, found a way to skip running css animations, but it only works in webkit

[20:56:54.0000] <zewt>
e.hidden = true; window.getComputedStyle(e).display; e.hidden = false; window.getComputedStyle(e).display;

[20:57:07.0000] <zewt>
no effect in ff or opera

[20:57:34.0000] <zewt>
transitions, rather

[21:00:38.0000] <Hixie>
do they not support .hidden?

[21:01:02.0000] <Hixie>
(why not just set a class that disables the animations?)

[21:01:24.0000] <zewt>
because i want to be able to skip animations and then start another animation immediately

[21:02:30.0000] <zewt>
(firefox definitely supports hidden, heh)

[21:45:22.0000] <zewt>
(in case anyone cares or googles their way to the above rambling, something that works in Firefox: http://pastebin.com/jUYVhC2X; opera equivalent doesn't work, though)

[22:05:28.0000] <Hixie>
anyone support border-image without prefix yet?

[22:43:14.0000] <Hixie>
is there any way to control the alignment of tiled border image pieces?

[22:49:39.0000] <Hixie>
wow, there really isn't?

[22:49:53.0000] <Hixie>
the second ever time i want to use border-image and it doesn't handle my use case :-( :-(

[03:22:17.0000] <matjas>
Hixie: the example on http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#global-identifiers-for-items uses itemprop="pubdate"; but it seems all schema.org schemas switched to itemprop="datePublished" instead. might make sense to update the example too

[03:28:39.0000] <adlwalrus>
Hi, why is this alt text not displaying? http://jsbin.com/esitef/1/edit

[03:36:52.0000] <Velmont>
/me heals after Ms2ger's poke

[04:55:26.0000] <Ms2ger>
Velmont, hey, do you have any more fileapi tests lying around?

[05:27:01.0000] <Velmont>
Ms2ger: Any more as if I had any at all? :P  I can check in Opera's repos on monday.

[05:46:44.0000] <Ms2ger>
Velmont, well, zcorpan (I think) submitted a few for new Blob(), but it would be nice to to duplicate work if you have any others

[05:53:59.0000] <Velmont>
Ms2ger: Yea, those. We probably have a few ones scattered about attached to bugs etc, but not always so easy to find. So I guess zcorpan sent the most relevant ones. Anyway, I'll look at it monday :]

[08:01:10.0000] <zewt>
cool, I just froze Opera

[08:01:16.0000] <zewt>
don't think that's ever happened to me before

[08:23:51.0000] <Velmont>
zewt: Hehe, you should do internal QA testing (I was mainline a few months), you'll get your fair share... :D

[08:26:20.0000] <zewt>
i've never worked QA and if I have any say I never will :P

[08:26:34.0000] <zewt>
i believe the phrase is "death for the dead"

[08:56:23.0000] <zewt>
http://dev.w3.org/csswg/css3-align/#overview best diagrams ever

[10:06:49.0000] <Hixie>
matjas: can you file a bug? (click on the example, type your IRC comment into the box at the bottom left, and click the button)

[11:22:02.0000] <hsivonen>
Philip`: how should I report bugs about your font subsetter?

[11:22:28.0000] <hsivonen>
Philip`: see http://hsivonen.iki.fi/test/font-subset/wikipedia.html

[11:27:50.0000] <hsivonen>
Philip`: As the full font case shows in Firefox, the font has ligatures for Th, ffi and Qu as well as an alternative glyph for W.

[11:28:01.0000] <hsivonen>
Philip`: When subset.pl is a given that the string "Wikipedia" as the set of characters to include, it properly includes the alternative glyph for W.

[11:28:09.0000] <hsivonen>
Philip`: However, when subset.pl is given the string "The efficient Wikipedia Queen" as the set of characters to include, it's verbose output claims to include (among others) the ligatures T_h, Q_u and f_f_i as well as W.alt. However, none of these actually show up in Firefox.

[11:29:32.0000] <hsivonen>
Philip`: Yet, the resulting font passes Firefox is OpenType validator since the font is used without ligatures and alternative glyphs.

[11:35:50.0000] <adlwalrus>
Hi all, I'm having some trouble interpreting this article: http://blogs.msdn.com/b/ie/archive/2012/02/20/google-bypassing-user-privacy-settings.aspx . What I'm trying to find out is whether a semantically meaningless P3P-CP header will cause IE* to accept or reject third party cookies that are set together with the CP.

[11:37:13.0000] <adlwalrus>
I mean when it comes across a P3PCP that it doesn't understand, will it say "can't understand this, so better safe than sorry / be conservative with user's privacy, so reject the cookie" or "can't make sense of this, but at least a CP was provided, so what the hell? *accept the cookie*"

[11:48:07.0000] <zewt>
(am I the only one that thinks there's something categorically silly about features that say "hey, I know you were planning on violating my privacy in every possible way you think you can profit from, but mind not doing that?")

[12:03:50.0000] <hsivonen>
Philip`: subset.pl generates invalid PostScript Font names. Intentional?

[14:23:51.0000] <MikeSmith>
adlwalrus: I think the only thing newsworthy about that article is the implication that any browser pays any any attention to P3P headers at all


2012-08-13
[23:20:00.0000] <zcorpan>
hello whatwg

[23:20:14.0000] <zcorpan>
what has happened in the past 4 weeks?

[23:42:58.0000] <hsivonen>
what's the deal with w3memes using the insanity wolf for reusing <link> or <meta> and the sanity wolf for addinga new void element to <head>?

[00:23:06.0000] <Ms2ger>
zcorpan, mm, the fork?

[00:23:33.0000] <zcorpan>
that was just before i left

[00:25:00.0000] <kennyluck>
2D context also gets an editorial team?

[01:34:32.0000] <odinho>
zcorpan: Ms2ger asked if you were lurking on more FileAPI tests. :]

[01:38:57.0000] <zcorpan>
Ms2ger: we have more file api tests but they're not using testharness

[01:39:36.0000] <jgraham>
zcorpan: As you can see, nothing of interest. I had some questions that I would have asked you, but you were on holiday so I didn't. Now I don't even remember what they were or whether I got htem answered (I think I did)

[01:40:22.0000] <zcorpan>
ok. thanks

[01:40:42.0000] <zcorpan>
then maybe i can mark all my email as read and get on with something more useful :-)

[01:43:44.0000] <odinho>
zcorpan: Nop, there's one you should read regarding foms.

[01:44:21.0000] <odinho>
(Also, I got jealous of moz #developers and made a #dev channel for Opera :P)

[01:54:08.0000] <zcorpan>
heycam: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17166

[01:58:25.0000] <kennyluck>
odinho, Opera internal IRC?

[01:59:11.0000] <odinho>
kennyluck: But of course ;-) Don't think we would've used MSN Messenger, do you? :P

[01:59:36.0000] <kennyluck>
odinho, it might be on irc.freenode.net. Who knows.

[02:00:11.0000] <odinho>
kennyluck: Oh, yeah, that was the main part -- might restrict us a bit though.

[02:27:03.0000] <heycam>
zcorpan, thanks, though I thought that bug was resolved

[02:27:17.0000] <heycam>
zcorpan, I guess it was the other identical bug

[02:28:34.0000] <heycam>
zcorpan, actually is it a dupe of https://www.w3.org/Bugs/Public/show_bug.cgi?id=18003 ?

[02:28:37.0000] <heycam>
/me goes to eat dinner

[04:10:02.0000] <zcorpan>
Hixie: http://code.google.com/p/chromium/issues/detail?id=49976 - now opera/firefox/chrome follow the link, maybe the spec should be changed...

[04:26:27.0000] <AryehGregor>
zcorpan or other Opera people: why does "Check for Updates" tell me I'm using the latest version of Opera, but "About Opera" says Opera Next 12.00 alpha and I see a 12.50 alpha for download?

[04:27:02.0000] <hsivonen>
AryehGregor: on Linux?

[04:27:06.0000] <AryehGregor>
Yes.

[04:27:21.0000] <hsivonen>
AryehGregor: if you installed from .deb, the updates always seem to be late

[04:28:49.0000] <odinho>
Yeah, it's not an a real railway track yet :P Hopefully it'll become a bit better after 12.50.

[04:34:11.0000] <kennyluck>
AryehGregor, are you using Opera or Opera Next? Opera Next updated me to 12.50 internal.

[04:34:24.0000] <AryehGregor>
kennyluck, Opera Next.

[04:34:47.0000] <kennyluck>
hmm… that's odd then. It works for me.

[04:48:00.0000] <zcorpan>
AryehGregor: i don't know. can you file a bug?

[04:48:28.0000] <AryehGregor>
zcorpan, I got bored a year or two ago of filing bugs in bug trackers I can't see and never got noticeable feedback on.

[04:48:43.0000] <AryehGregor>
/me updated manually

[04:49:39.0000] <zcorpan>
AryehGregor: ok

[05:52:41.0000] <hsivonen>
AryehGregor: what does "manually" mean? AFAICT, Ubuntu doesn't update Opera, Chrome, Spotify, etc., as soon as updates become available. it updates them only as a side effect of updating some packages coming from Ubuntu repos.

[05:53:07.0000] <AryehGregor>
hsivonen, by downloading the new .deb from opera.com in a web browsers.

[05:53:23.0000] <AryehGregor>
I think Opera 12.50 has been available for longer than the time since I last updated.

[05:53:35.0000] <AryehGregor>
But Ubuntu disables third-party repos on OS upgrade, maybe that's the problem.

[05:53:59.0000] <AryehGregor>
Chrome works around it by occasionally checking if the repo is enabled and re-enabling it if it's not, I think, or something like that.

[06:13:28.0000] <odinho>
Hmm. That might be a good idea.

[06:28:42.0000] <hsivonen>
When will ftp: join gopher: in the graveyard cross-browser...

[07:00:15.0000] <zewt>
hsivonen: given that it's useful, still used all the time and has no serious replacement, i would think not soon, heh

[07:12:55.0000] <odinho>
AryehGregor, hsivonen: So, it should be fixed for further releases the desktop people say. I hope so, I've had to do a few manual ones myself.

[08:36:23.0000] <hsivonen>
Hixie: In my experience, it's possible to browse with 1rem = 18px without breaking the Web

[08:36:41.0000] <hsivonen>
I wouldn't be surprised if 1rem = 14px worked, too.

[08:37:15.0000] <hsivonen>
(I've used 1rem = 18px for years and years)

[08:37:44.0000] <hsivonen>
(Of course, the unit "rem" hasn't existed for that long, but you know what I mean.)

[08:48:24.0000] <hsivonen>
will anyone ever in practice supply images with sampling other than 1 image pixel per CSS pixel and 2 image pixels per CSS pixel?

[08:52:19.0000] <jgraham>
hsivonen: It seems hard to know and bad to bake into the spec that those are the only values allowed

[08:54:23.0000] <hsivonen>
jgraham: baking it in the spec would sure simplify things

[08:54:45.0000] <jgraham>
Simplify which things?

[08:55:06.0000] <dglazkov>
good morning, Whatwg!

[08:55:07.0000] <hsivonen>
if Apple is using 2x for "retina" and "retina" means a human eye can't tell the pixels apart, why would anyone bother with more than 2x ever?

[08:55:18.0000] <hsivonen>
for photos that is

[08:55:28.0000] <hsivonen>
for sharp line art you should use SVG anyway

[08:55:56.0000] <hsivonen>
jgraham: well, we could have just src and hisrc if there are two samplings and art direction is ignored

[08:56:13.0000] <hsivonen>
then art direction could be a different syntactic axis

[08:56:23.0000] <jgraham>
Well it seems that real devices are already bothering with > 2x

[08:56:51.0000] <hsivonen>
for example?

[08:57:25.0000] <hsivonen>
hah. Hixie's email is so epically long that Gmail clips it

[08:57:39.0000] <jgraham>
Pretty sure florian mentions some later in the thread

[08:57:56.0000] <jgraham>
And without looking at any of the actual facts, colour me skeptical that the most convenient resolution for Apple given its legacy constraints happens to be the maximum resolution that anyone will ever want

[08:59:00.0000] <Ms2ger>
Why not src and lowsrc? ;)

[09:00:46.0000] <hsivonen>
I said hisrc as an analogy with lowsrc, since I'm old enough to remember

[09:01:52.0000] <Ms2ger>
hsivonen, oh, this is you: http://25.media.tumblr.com/tumblr_m7hawuJGGS1rvsbh9o1_500.jpg ?

[09:07:04.0000] <hsivonen>
jgraham: existence proof of devices with non-1-or-2 device pixel ratios is no proof that author will bother to supply more bitmap samplins than 1 and 2

[09:08:04.0000] <hsivonen>
jgraham: given how hard it is to get authors to care about non-Apple mobile browsers, good luck getting authors to supply a 1.25 factor sampling

[09:09:59.0000] <jgraham>
hsivonen: I don't think arguing that authors only care about Apple products so we should just do whatever maps most closely to Apple's current hardware is a good one to make either in principle or in practice

[09:53:12.0000] <Hixie>
hsivonen: zoom to 200% and you're already needing 4x images

[09:53:18.0000] <Hixie>
today

[09:56:09.0000] <Hixie>
jgraham: especially given that even apple is so early on in this cycle that they haven't finished transitioning to it

[09:56:32.0000] <Hixie>
hsivonen: (btw, macbook pro's "retina" isn't "true retina" by apple's own standards, as i understand it)

[09:56:44.0000] <Hixie>
(though as a user i have to say it's damn nice)

[10:13:56.0000] <hsivonen>
Hixie: I admit that it would be nice to be able to implement photo zooming without site-side logic

[10:14:57.0000] <hsivonen>
(so that zooming on a Flickr page would eventually show the original size from camera without JS)

[10:15:09.0000] <hsivonen>
seems like and edge case, though

[10:16:56.0000] <Hixie>
you think more people have Apple retina displays than zoom? that seems... unlikely, especially given how prevalent zooming is on mobile phones

[10:20:41.0000] <hsivonen>
interesting that http://www.davidmacd.com/WCAG/WAI/buggy.html recommends removing all the examples it mentions and doesn't recommend *correcting* any of them

[10:21:35.0000] <hsivonen>
Hixie: but is zooming on phones deeper than 1x field of view on desktop prevalent?

[10:23:00.0000] <Hixie>
hsivonen: i certainly do it, but i have no data one way or the other. Zooming the other way (also supported in the spec) is certainly prevalent.

[10:30:53.0000] <Ms2ger>
<iframe></iframe>

[10:30:59.0000] <Ms2ger>
window[0] = "foo"

[10:31:04.0000] <Ms2ger>
What is window[0]?

[10:33:27.0000] <Hixie>
WindowProxy object to the Window inside the browsing context of the iframe

[10:33:30.0000] <Hixie>
oh wait

[10:33:34.0000] <Hixie>
i missed the = "foo"

[10:33:47.0000] <Hixie>
so that becomes a webidl question, ping heycam|away :-)

[10:34:10.0000] <weinig>
nice passing the buck

[10:34:13.0000] <weinig>
:)

[10:35:22.0000] <Hixie>
:-)

[10:36:29.0000] <Ms2ger>
Hixie, Firefox still does what you suggest :)

[10:36:42.0000] <Hixie>
Ms2ger: that'd be my preferred answer

[10:36:50.0000] <Hixie>
Ms2ger: but i don't know if it's what the idl requires

[10:37:18.0000] <Ms2ger>
I think it might be

[10:37:33.0000] <Ms2ger>
Only I have no idea how the Gecko code does it :)

[13:53:46.0000] <smaug____>
dglazkov: hey, does shadow DOM already support default handling for events

[13:53:58.0000] <smaug____>
I mean, is it possible to define default handler

[14:10:59.0000] <dglazkov>
smaug____: no, there's no plumbing for that. Give me an example of where it could be useful. I can file a bug.

[14:14:50.0000] <smaug____>
dglazkov: well, if you want to implement something like <a> using shadow dom

[14:14:54.0000] <smaug____>
or a form control

[14:15:04.0000] <smaug____>
you may want to default handling click event

[14:15:18.0000] <smaug____>
s/handling/handle/

[14:19:31.0000] <dglazkov>
smaug____: ah, I see. This is actually necessary if we try to implement built-in elements. Right.

[14:19:40.0000] <dglazkov>
smaug____: I'll file a bug

[14:36:49.0000] <smaug____>
thanks

[15:27:26.0000] <zewt>
am I going blind or is there no way to tell whether a popstate is a forward or negative navigation

[15:29:11.0000] <zewt>
uh ... backward, even, heh

[16:05:32.0000] <Hixie>
zewt: it's in the event object iirc

[16:11:02.0000] <zewt>
Hixie: in PopStateEvent? that only has .state (null when pushState/replaceState aren't used)

[16:14:24.0000] <Hixie>
oh maybe i'm thinking of pageshow/pagehide

[16:14:58.0000] <Hixie>
yeah, nevermind

[16:15:33.0000] <Hixie>
what's your use case exactly? maybe there's something we shoudl add

[16:16:38.0000] <zewt>
transitions

[16:17:11.0000] <zewt>
the page has left/right transitions internally for its own navigations; i want back/forward navigations to mimic it, since it's weird if browser nav always goes right

[16:18:48.0000] <Hixie>
interesting

[16:49:31.0000] <heycam>
Hixie, if an interface supports indexed properties but without an indexed property setter/creator, then an assignment like that will throw an exception in strict mode, and be ignored in non-strict mode


2012-08-14
[17:37:32.0000] <hober>
does anyone know where the original (no text) image in http://w3cmemes.tumblr.com/post/22670112919 came from?

[17:39:29.0000] <hober>
nvm, found it.

[00:04:46.0000] <zcorpan>
web-apps-tracker gives 500 :-(

[00:07:51.0000] <jgraham>
annevk is away

[01:16:44.0000] <zcorpan>
Hixie: that's one ugly fingerprint image

[01:36:37.0000] <zcorpan>
Hixie: how about http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1697

[02:14:39.0000] <jgraham>
zcorpan: Write that all by hand in the live dom viewer? ;)

[02:15:22.0000] <zcorpan>
read the comments :-P

[02:39:42.0000] <jgraham>
Didn't roc have a blogpost defining what makes something part of the open web?

[04:04:53.0000] <odinho>
Anyone want to talk IndexedDB? createIndex and "" keyPath, specifically.

[04:05:25.0000] <odinho>
This channel has not typically been very good on idb talk though :-/ Maybe I should try #webapps too before going to teh emailz.

[04:07:10.0000] <jgraham>
odinho: Since si fails to tab complete "sicking" I doubt anyone wants to discuss IndexedDB :p

[04:07:58.0000] <odinho>
jgraham: Yeah, he's more often in webapps though, he left there some time ago. He should be available in european work hours if you ask me!

[04:09:18.0000] <jgraham>
Convinve him that california doesn't have enough pickled herring and that he should move back here :)

[04:42:56.0000] <jgraham>
Does chrome really have no better UI for redisabling popups on a domain where you previously allowed them than editing the config file by hand?

[06:08:48.0000] <hsivonen_>
do I read correctly that there's a FO against not letting keyboard focus for sighted users move into @hidden subtrees?

[06:10:45.0000] <hsivonen>
oh, the FO is against letting focus go into the @hidden subtree

[06:50:30.0000] <Stevef_>
hsivonen:focus doesn't move into a @hidden subtree as far as I know

[06:52:02.0000] <hsivonen>
Stevef_: with the prevailing CP applied? in screenreader case or in visual+keyboard case?

[06:53:08.0000] <Stevef_>
hsivonen: in general, I don't understand the effects of the CP

[06:59:38.0000] <Stevef_>
hsivonen:either @hidden subtree is hidden from everyone so it cannot be navigated or its not so it can be navigated. when an image references a link using aria-describebdby it does not make the link focusable, it adds a default accessible action to the visible image, so that the link can be navigated to. that is how it works in the only implementation we have (firefox)

[07:00:24.0000] <Stevef_>
hsivonen: FYI not arguing merits of any CP btw

[07:01:05.0000] <Stevef_>
hsivonen: the whole thing has been bent out of shape me thinks

[07:02:18.0000] <Stevef_>
how it works in firefox: http://www.paciellogroup.com/blog/2012/05/firefox-14-image-long-description-via-link-using-aria-describedby/

[07:03:27.0000] <Stevef_>
not a lot of use unless implemented across browsers though, same issue as longdesc

[07:13:44.0000] <hsivonen>
Stevef_: oh so with @hidden, it becomes a verbose and indirect equivalent of longdesc?

[07:14:38.0000] <hsivonen>
what happen is aria-descibedby points to an ancestor of the <a> instead of the <a> itself?

[07:14:43.0000] <hsivonen>
*happens

[07:15:19.0000] <Stevef_>
hsivonen: yes, in firefox usese same default action exposed for longdesc, note the link does not need to be hidden for it to work

[07:16:11.0000] <hsivonen>
yeah, the non-hidden case makes sense and the @hidden case only as a sidekick of the non-@hidden case

[07:16:22.0000] <hsivonen>
the @hidden case alone wouldn't be much of an improvement

[07:16:41.0000] <Stevef_>
hsivonen: the acc description is the text in the container element, it must directly reference a link AFAIK for the default action to be exposed

[07:17:05.0000] <hsivonen>
ok

[07:18:04.0000] <Stevef_>
hsivonen: i may suggest its use in the non hidden case, but the hidden case is well 'hidden' same as longdesc not a lot of use unless it is supported across the board, so would have to provided a visible link anyway...

[07:20:28.0000] <hsivonen>
Stevef_: the prevailing CP is broader than the Firefox feature you described

[07:20:51.0000] <hsivonen>
Stevef_: one could even argue the Firefox behavior is slightly wrong under the prevailing CP

[07:21:16.0000] <hsivonen>
I guess I will let other people debate it now that I see the difference. Thanks.

[07:21:47.0000] <Stevef_>
hsivonen: I do not see a use case for the exposing of lots of hidden content to AT only

[07:22:58.0000] <Stevef_>
hsivonen: I am unclear about any of the CPs, none appear overly useful to me

[07:29:48.0000] <Stevef_>
/me "I guess I will let other people debate it" yes

[08:08:43.0000] <jgraham>
Huh, what does gecko do for location.reload(argument) ?

[08:09:18.0000] <jgraham>
For reasons I don't entirely understand, Opera has location.reload(bool force)

[08:09:42.0000] <jgraham>
With force = true meaning "don't reload from cache"

[08:09:57.0000] <jgraham>
But gecko seems to have almost the opposite behaviour

[08:10:13.0000] <zewt>
iirc webkit location.reload() with no argument forces a reload

[08:10:29.0000] <zewt>
hit that yesterday, had to change a bunch of location.reload to location.href = location.href to make sure it's just a refresh

[08:11:40.0000] <jgraham>
zewt: Per the TC I am looking at it seems that gecko and webkit have different behaviours for an iframe compared to a top level browsing context

[08:11:51.0000] <jgraham>
For an iframe webkit always force-reloads

[08:12:09.0000] <jgraham>
Gecko also, I think

[08:12:32.0000] <jgraham>
For a tlbc WebKit never force reloads, Gecko only does if you pass in false

[08:12:34.0000] <zewt>
this was just a top-level window

[08:12:40.0000] <jgraham>
Hmm

[08:13:14.0000] <zewt>
i can recheck, i saw it reloading images though

[08:13:54.0000] <smaug____>
/me looks at location implementation

[08:14:19.0000] <smaug____>
btw, assign() has been implemented in different ways in different browsers

[08:15:04.0000] <smaug____>
reload(true) sets the flags to bypass cache

[08:15:22.0000] <jgraham>
smaug____: The "if the session history contains only one document and that's the about:blank document" bit, or something else?

[08:15:45.0000] <smaug____>
those flags don't have anything to do with session history

[08:16:36.0000] <jgraham>
smaug____: I meant for "assign"

[08:17:11.0000] <smaug____>
oh

[08:17:25.0000] <jgraham>
smaug____: I swear that this TC shows gecko having exactly the opposite behaviour for reload :)

[08:18:09.0000] <smaug____>
https://bugzilla.mozilla.org/show_bug.cgi?id=754029#c50

[08:20:00.0000] <jgraham>
I don't really understand that comment

[08:20:08.0000] <jgraham>
Maybe I will if I read the other 49

[08:20:43.0000] <jgraham>
Everything about history makes me cry

[08:21:11.0000] <jgraham>
Who knew that the fundamental navigation metaphor of the web was so incompatible across implementations

[08:22:14.0000] <zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18542 soooo i guess firefox should rename wheel to mousewheel and d3e has to suck it up

[08:22:26.0000] <jgraham>
smaug____: If you break the spec here, you will file a bug and CC me, right?

[08:23:40.0000] <zcorpan>
$ grep -aPic "\sonwheel\s*=" web200904

[08:23:41.0000] <zcorpan>
0

[08:24:25.0000] <smaug____>
jgraham: break the spec where :) all session history handling is underspec'ed

[08:25:09.0000] <smaug____>
jgraham: obviously you want to write a spec for it... can't wait to see it ;)

[08:27:21.0000] <jgraham>
smaug____: Hixie wants to write a spec for it :p

[08:27:35.0000] <jgraham>
Indeed that's what he gets paid the big bucks to do

[08:27:41.0000] <jgraham>
/me finds https://www.w3.org/Bugs/Public/show_bug.cgi?id=17041

[08:29:10.0000] <jgraham>
smaug____: But it isn't much help to anyone if no one is even reporting bugs on the issues

[08:29:21.0000] <jgraham>
(although bz did in this case)

[08:29:34.0000] <jgraham>
Because then the spec will just continue being wrong

[08:30:36.0000] <jgraham>
(and implementations will continue being incompatible)

[08:32:49.0000] <jgraham>
(ideally people would also submit testcases, although I understand why that can be difficult)

[08:33:46.0000] <smaug____>
it has been a bit hard to file bugs, when the spec seems to miss so many things

[08:34:13.0000] <jgraham>
It has been a bit hard to make our implementation match others when they didn't bother to file bugs :)

[08:34:35.0000] <smaug____>
yup

[08:34:41.0000] <smaug____>
/me has tried to follow IE

[08:34:48.0000] <jgraham>
/me has tried to file bugs

[08:35:04.0000] <jgraham>
And I think I have largely succeeded

[08:35:09.0000] <smaug____>
since it has traditionally have the least badly behaving sh implementation

[08:35:31.0000] <jgraham>
That is, every time we have found that we have to deviate from the spec, I have tried to file a bug

[08:35:54.0000] <jgraham>
I probably missed some, but it hasn't been impossible

[08:38:40.0000] <Hixie>
zcorpan: that license doesn't allow commercial re-use, as far as i can tell. plus, hey, it's not that ugly :-P

[08:38:50.0000] <Hixie>
smaug____: it's not _that_ underdefined any more is it? :-)

[08:39:05.0000] <Hixie>
hsivonen: note that the CPs in question apply to a part of the spec that has long since forked in the WHATWG space

[08:39:34.0000] <zcorpan>
Hixie: dang. well, i still stand by that it's ugly :-P

[08:41:10.0000] <Hixie>
:-P

[08:41:22.0000] <zcorpan>
Hixie: scan your own finger print and use that :-)

[08:41:47.0000] <Hixie>
technically iirc the picture was a picture of my own fingerprint, drawn in Markers on android :-)

[08:42:44.0000] <Hixie>
unfortunately with the size of my screen and the size of my finger it's like trying to draw with a felt tip pen on a postage stamp

[08:42:52.0000] <Hixie>
i really need a tablet or something

[08:46:13.0000] <jgraham>
Just ask the original author to relicense it

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

[09:02:50.0000] <Ms2ger>
G'day

[10:02:43.0000] <zewt>
man, ontransitionend is a nightmare

[10:02:44.0000] <Ms2ger>
<link rel=intent>

[10:02:52.0000] <Ms2ger>
Hixie is going to be so happy

[10:03:30.0000] <zewt>
need to jump all kinds of hoops to figure out whether a particular style change will trigger it, and if you get it wrong you miss the event and likely fall apart

[10:06:11.0000] <tantek>
Ms2ger - why are intents special? We already have a way to link to application manifests, which include, among other things, what "activities" an app will handle.

[10:06:17.0000] <tantek>
no need for separate links to intents

[10:06:26.0000] <tantek>
app manifests already cover this

[10:06:43.0000] <hober>
also, why are we propagating the crazy word "intent" for this?

[10:06:46.0000] <tantek>
this smells of the "my feature is so important it deserves it's own element" reasoning

[10:06:49.0000] <tantek>
yeah

[10:07:07.0000] <hober>
"capability" or "action" would at least *make sense*

[10:07:35.0000] <miketaylr>
+1

[10:12:26.0000] <tantek>
hober - yeah, hence "web actions"

[10:13:40.0000] <hsivonen>
Ms2ger: Hixie's happiness comes last in the priority of constituents

[10:14:39.0000] <Ms2ger>
hsivonen, I would put a few other persons' happiness a little later still ;)

[10:14:45.0000] <tantek>
per "my feature is so important…" design: http://w3cmemes.tumblr.com/post/22399681762

[10:15:05.0000] <tantek>
the lesser version of that is, "my feature/company is so important, it needs its own rel value"

[10:16:12.0000] <tantek>
btw, the aforementioned app manifest spec: http://mozilla.github.com/webapps-spec/

[10:16:33.0000] <tantek>
Hober - I would welcome a "capability" addition to that spec

[10:16:45.0000] <tantek>
so we don't have invent yet another special case code path for something like "intents"

[10:17:01.0000] <tantek>
that's where this kind of thing (intents/activities) belongs

[10:17:12.0000] <tantek>
in the app manifest that describes all sorts of things about what the app does / needs.

[10:17:14.0000] <hsivonen>
I wonder who chose wolves at http://25.media.tumblr.com/tumblr_m8iuvfm9o81rvsbh9o1_500.jpg and http://24.media.tumblr.com/tumblr_m8iuliq6Ns1rvsbh9o2_500.jpg ...

[10:18:00.0000] <Ms2ger>
hsivonen, I believe Insanity Wolf did

[10:18:51.0000] <tantek>
hober, here's the current "capability" style declaration that we're adding to the app manifest in a declarative way that serves the same purpose as Google's intents: https://wiki.mozilla.org/WebAPI/WebActivities#Declarative_registration

[10:19:01.0000] <tantek>
add that to the aforementioned app manifest and you're good to go

[10:19:07.0000] <tantek>
no need for new elements, nor rel values

[10:19:30.0000] <Ms2ger>
Everything solved

[10:19:33.0000] <Ms2ger>
Let's go shopping

[10:20:47.0000] <tantek>
Ms2ger - they will be once we ship that support in FirefoxOS on devices.

[10:21:00.0000] <tantek>
But you'll have to go to Brazil to shop for those (for now)

[10:22:40.0000] <Ms2ger>
I sure am glad that the b2g team can solve every single problem in this industry on their own.

[10:23:44.0000] <tantek>
Ms2ger - no, just the ones that DAP/W3C have failed to solve.

[10:24:00.0000] <tantek>
And you know the drill, patches welcome ;)

[10:24:18.0000] <Ms2ger>
/me can't remember any problem DAP solved

[10:24:20.0000] <tantek>
you're welcome to /join #webapi on irc.mozilla.org

[10:24:29.0000] <jgraham>
/me finds the idea of general purpose manifests more scary than intents

[10:24:33.0000] <Hixie>
hsivonen: nah, theoretical purity comes even after that :-)

[10:24:43.0000] <tantek>
and speak your critically rational mind :)

[10:24:48.0000] <hsivonen>
Hixie: can it be happy?

[10:24:55.0000] <Ms2ger>
tantek, thanks for proving the point :)

[10:25:12.0000] <jgraham>
tantek: The right solution to "W3C failed to solve this problem" is not "let's invent a proprietry solution"

[10:25:14.0000] <Hixie>
hsivonen: the people who care about it can be :-)

[10:25:22.0000] <tantek>
jgraham - nothing proprietary about it

[10:25:27.0000] <hsivonen>
Hixie: fair enough

[10:25:38.0000] <tantek>
it's a counterproposal to W3C/DAP drafts that failed (or are failing)

[10:25:52.0000] <hsivonen>
tantek: well, there's a whole lot of "moz" prefixing in WebAPI

[10:25:59.0000] <jgraham>
tantek: Which open forum is being used to develop the spec?

[10:26:08.0000] <tantek>
hsivonen - I'm not a fan of moz prefixing in WebAPI - I've been changing my mind on that

[10:26:15.0000] <jgraham>
A mozilla-specific IRC channel doesn't count

[10:26:22.0000] <tantek>
why? it's open

[10:26:51.0000] <tantek>
or you just hating on the string "mozilla" ?

[10:27:01.0000] <Ms2ger>
/me yawns

[10:27:08.0000] <smaug____>
;)

[10:27:09.0000] <Ms2ger>
This has been discussed often enough

[10:27:11.0000] <jgraham>
It clearly signals ownership

[10:27:27.0000] <jgraham>
You should do it at WHATWG if you are serious about it being non-proprietary

[10:27:30.0000] <tantek>
unlike a spec that only has editors from a single company?

[10:28:07.0000] <tantek>
WHATWG has no monopoly on non-proprietariness

[10:28:09.0000] <jgraham>
If *that* was a criterion then pretty much every non-CSS spec would be proprietary

[10:28:28.0000] <tantek>
nah - just the specs with heaps of Google editors

[10:28:37.0000] <Ms2ger>
What makes you think we like those?

[10:28:39.0000] <jgraham>
And CSS would only get by because no one actually ever finishes the damn specs

[10:28:41.0000] <tantek>
(and no other companies represented)

[10:29:01.0000] <tantek>
jgraham - I though

[10:29:13.0000] <Hixie>
(what makes you think even _google_ likes those?)

[10:29:15.0000] <jgraham>
Sure, there are things that Google are doing that should be more open

[10:29:25.0000] <tantek>
thought* "no[t] finish[ing] damn specs" was preferred here at WHATWG ;)

[10:29:30.0000] <jgraham>
That doesn't give Moz. a free pass to be just as bad

[10:29:31.0000] <tantek>
AKA "living specs"

[10:29:54.0000] <jgraham>
tantek: The CSS specs I have in mind spent years as more dead than alive

[10:30:08.0000] <tantek>
jgraham, sorry I couldn't read your mind for particular strawmen.

[10:30:18.0000] <Ms2ger>
Are you going off on a tangent because you agree that those WebAPI specs are proprietary?

[10:30:24.0000] <jgraham>
(in fact Mozilla holds itself to a higher standard, so you shouldn't be surprised when other people also hold you to a higher standard)

[10:30:42.0000] <tantek>
if you have any particular favorite CSS specs you'd like to see resuscitated, let me and hober and tabatkins know - we're sitting in the CSSWG f2f now

[10:31:02.0000] <tantek>
jgraham - absolutely - keep it up

[10:31:05.0000] <Ms2ger>
CSS3-UI

[10:31:09.0000] <hober>
hahahahahahaa

[10:31:17.0000] <hsivonen>
/me would prefer Google's SPDY over an "open" HTTP/2.0 that has had people in the intercept business water it down

[10:31:31.0000] <jgraham>
My point is that CSS is pretty much the only group that regularly has multiple editors from multiple compaies per spec

[10:31:39.0000] <tantek>
Ms2ger - what edits do you need/want in CSS3-UI

[10:31:41.0000] <tantek>
?

[10:31:55.0000] <Hixie>
specs shouldn't have multiple editors, it just leads to shared credit and diluted blame

[10:32:16.0000] <Ms2ger>
tantek, implementations

[10:32:18.0000] <Hixie>
specs should have a single editor who is given full responsibility and who is clearly entirely to blame when mistakes are made

[10:32:19.0000] <tantek>
Hixie - my experience has been to the contrary many times

[10:32:23.0000] <Hixie>
that's the way you ensure quality

[10:32:24.0000] <Ms2ger>
Oh, and tests

[10:32:30.0000] <smaug____>
jgraham: WebApps how often multiple editors, and at least feedback from multiple companies

[10:32:37.0000] <smaug____>
s/how/has/

[10:32:43.0000] <tantek>
The most recent  CSS3-UI  last call closed, and I'm looking at *dropping* features that didn't get implemented

[10:32:47.0000] <jgraham>
I don't care who *writes* the specs

[10:32:51.0000] <tantek>
like all the nav-* stuff

[10:33:01.0000] <tantek>
Ms2ger - most of CSS3-UI is implementee

[10:33:03.0000] <jgraham>
Except insofar as some people are better at it than others

[10:33:05.0000] <tantek>
implemented* even

[10:33:13.0000] <tantek>
which features in particular are you missing?

[10:33:29.0000] <tantek>
and yes, tests needed. contributions welcome.

[10:33:36.0000] <tantek>
(which is true for nearly all specs)

[10:34:11.0000] <jgraham>
I care about the specs having a development process that encourages feedback from multiple sources and is likely to lead to multiple interoperable implementations

[10:34:27.0000] <tantek>
jgraham - of course

[10:34:42.0000] <hsivonen>
(I still don't see the upside of letting the IETF get its hands on SPDY. https://plus.google.com/100166083286297802191/posts/hoYbGxrSuWm )

[10:34:48.0000] <jgraham>
However you cut it "Mozilla IRC channels" are not a venue that encourages feedback from multiple vendors

[10:34:57.0000] <hober>
jgraham: weird. :)

[10:35:01.0000] <tantek>
hsivonen - what is the upside of letting IETF get its hands on anything?

[10:35:16.0000] <tantek>
jgraham - plenty of non-mozilla people in mozilla IRC channels

[10:35:22.0000] <Hixie>
(examples: CSS2.1, SVG, HTML4, DOM3 Events, Selectors, backgrounds&borders -- all specs where nobody has taken full responsibility for the problems, but lots of people have claimed credit for the successes)

[10:35:35.0000] <Ms2ger>
Hixie, DOM4? :)

[10:35:37.0000] <Hixie>
(i'm one of those with 2.1, e.g.)

[10:35:40.0000] <hsivonen>
tantek: in theory, getting adoption and interop, but SPDY seems doing fine on those points without the IETF

[10:35:46.0000] <jgraham>
tantek: So what?

[10:35:47.0000] <Hixie>
Ms2ger: that one hasn't had problems to take responsibility for, so far :-)

[10:35:51.0000] <tantek>
Hixie, I think we've both shared plenty of blame on 2.1

[10:35:56.0000] <Hixie>
tantek: exactly

[10:35:58.0000] <jgraham>
tantek: Why won't you bring those specs to whatwg?

[10:36:14.0000] <Hixie>
tantek: yet neither of us has done anything about it

[10:36:23.0000] <tantek>
jgraham, me personally? email-centric culture sucks. others? you're welcome to ask the editors.

[10:36:35.0000] <Ms2ger>
Email is a support forim

[10:36:43.0000] <Ms2ger>
Just so we got that behind us

[10:36:46.0000] <tantek>
thank you Ms2ger ;)

[10:36:58.0000] <Hixie>
spec development and discussion should happen on twitter!

[10:37:14.0000] <tantek>
Hixie - I'm back at the CSSWG f2f meetings and such trying to help improve the CSS specs. As are the rest of the people in the room.

[10:37:31.0000] <Hixie>
tantek: meetings don't improve specs

[10:37:39.0000] <Ms2ger>
F2F meetings are a support forum?

[10:37:44.0000] <odinho_>
Yes

[10:38:13.0000] <tantek>
Hixie, I've seen smaller meetings, e.g. between Tab and fantasai - drastically improve specs

[10:38:23.0000] <tantek>
there are plenty of counter-examples to your general assertion

[10:38:37.0000] <tantek>
meetings can easily be completely unproductive -  but doesn't mean they always are.

[10:38:47.0000] <Ms2ger>
The claim was clearly about WG meetings

[10:38:48.0000] <tantek>
anyway - it's one way of "doing something about it"

[10:39:02.0000] <Ms2ger>
Not sure why you're trying a strawman again

[10:39:16.0000] <tantek>
Ms2ger - which WG meeting(s) have you participated in ?

[10:39:41.0000] <tantek>
or are you merely armchair commenting about them?

[10:39:52.0000] <Ms2ger>
I'm not commenting about them, Hixie is

[10:40:01.0000] <odinho>
tantek: You don't need to participate in person to see how they work. And what output it has on the spec afterwards.

[10:40:02.0000] <Hixie>
he was correctly interpreting my statement

[10:40:05.0000] <Ms2ger>
Are you deliberately misunderstanding?

[10:40:33.0000] <Ms2ger>
* fantasai is totally ignoring this entire discussion because we've had the exact same discussion with the exact same points at every single one of the past F2Fs since Exclusions was proposed.

[10:40:36.0000] <tantek>
odinho - hence "armchair"

[10:40:52.0000] <Ms2ger>
I guess that's a relevant point from a F2F participant

[10:41:08.0000] <tantek>
grids/exclusions tend to be very contentious yeah, unfortunately

[10:44:45.0000] <jgraham>
tantek: I am convinced that WHATWG participants would be flexible about how they gave feedback on specs if they felt that the spec was sufficiently valuable

[10:45:08.0000] <Hixie>
yeah there's nothing about the whatwg that says spec editors have to use the mailing list for feedback

[10:45:17.0000] <Hixie>
i'm happy to help people set up whatever mechanisms people want

[10:45:23.0000] <Hixie>
and the w3c has in the past helped too

[10:45:27.0000] <Hixie>
e.g. we use their bugzilla

[10:45:36.0000] <Hixie>
we have a web forum, a blog, a wiki

[10:45:52.0000] <Hixie>
all of which are available to any editors (or anyone else) who needs and wants to use them

[10:46:05.0000] <Hixie>
also this IRC channel, and anyone can of course set up new ones

[10:46:29.0000] <tantek>
Hixie, not everyone seems to agree with your sentiment that "anyone can of course set up new ones"

[10:46:32.0000] <Hixie>
the twitter account's password is available to anyone who wants to use it, should spec-feedback-by-twitter be a serious desire

[10:46:43.0000] <tantek>
which is essentially exactly what's happened with WebAPIs

[10:46:47.0000] <Hixie>
tantek: it's literally as easy as typing /join #foo

[10:47:54.0000] <jgraham>
tantek: I see no evidence that WebAPIs are being edited in any sort of vendor-neutral space. It appears to be a Mozilla-internal thing that just happens to be public because lots of Mozilla things are in public

[10:48:57.0000] <tantek>
jgraham - I'd like to see the specs edited in a more vendor neutral space as well. That being said, public input is certainly being encouraged an incorporated.

[10:49:00.0000] <hsivonen>
tantek: Regarding the Mozilla-specific also Web API, I think design decisions such as the one involved in https://bugzilla.mozilla.org/show_bug.cgi?id=774621 (IIRC, the only Web API design decision for which my input has been specifically solicited) could benefit from multi-vendor exposure.

[10:49:31.0000] <tantek>
hsivonen - *in general* design decisions on WebAPIs could benefit from multi-vendor exposure.

[10:49:41.0000] <hsivonen>
s/specific also/specificness/

[10:49:51.0000] <Hixie>
lordy, an sms api

[10:49:56.0000] <Hixie>
i remember speccing one of those back at opera

[10:50:01.0000] <hober>
Hixie: bleah

[10:50:04.0000] <Hixie>
good to know that doing that is still in fashion

[10:50:04.0000] <tantek>
Hixie - the full list is here: https://wiki.mozilla.org/WebAPI/

[10:50:16.0000] <tantek>
Hixie, yeah, people seems to use SMS a lot. Who knew?

[10:50:19.0000] <Hixie>
tantek: i've seen it (tried to adopt some of them for the web intents proposal i made)

[10:50:19.0000] <hsivonen>
Hixie: Opera FIRST!

[10:50:26.0000] <Hixie>
hsivonen: oh we weren't first

[10:50:36.0000] <Hixie>
hsivonen: my own api for this was informed by prior art

[10:50:42.0000] <tantek>
if email lists are your thing, there's also https://lists.mozilla.org/listinfo/dev-webapi

[10:52:20.0000] <Hixie>
tantek: btw, in general in my experence when a vendor A tells another vendor B that they feel that work is being done by B in a vendor-specific way, it doesn't matter if A is right or wrong; the technology will fail as a multi-vendor standard unless changes are made to make A feel like it's vendor-neutral.

[10:52:55.0000] <Hixie>
tantek: (not commenting in particular on the mozilla thing here, nor on whether google is any good at this either)

[10:53:19.0000] <tantek>
Hixie, indeed that's a common pattern

[10:53:20.0000] <tantek>
and a risk

[10:54:49.0000] <hsivonen>
Hixie: does Opera Mobile ship the API you designed?

[10:55:06.0000] <Hixie>
hsivonen: no idea, i spent as little time as possible on that proprietary api as i could

[10:55:26.0000] <jgraham>
(not as far as I know)

[10:55:36.0000] <Hixie>
(opera requiring me to spend any time on proprietary stuff at all was one of the reasons i looked for alternate employment)

[10:56:16.0000] <jgraham>
(but I don't know much about non-Web APIs)

[10:56:55.0000] <hsivonen>
What happened to Opera Platform from 2006 or so?

[10:59:40.0000] <jgraham>
/me wonders who might know that kind of thing

[11:05:57.0000] <Ms2ger>
hsivonen, oh, dunno if you saw the sniffing issues people had with Mozilla's ZIP API, I thought you might be interested

[11:06:21.0000] <hsivonen>
Ms2ger: I did

[11:08:51.0000] <hsivonen>
Ms2ger: I saw https://bugzilla.mozilla.org/show_bug.cgi?id=781425

[11:09:38.0000] <Ms2ger>
That's the one I was thinking of, according to firebot

[14:09:24.0000] <zewt>
opera doesn't do pointer-events? seriously?

[14:14:28.0000] <smaug____>
svg pointer-events I guess

[14:14:34.0000] <smaug____>
not MS Pointer Events

[14:14:55.0000] <miketaylr>
opera has svg pointer-events, not the CSS ones currently

[14:22:36.0000] <tantek>
zewt - what's your use case for pointer-events? which value(s) in particular in what situation? (honest question as I'm likely to be the one speccing it in css4-ui)

[14:24:24.0000] <zewt>
i'm using it to make sure things that use CSS opacity:0 transitions aren't clickable when they're hidden, to disable clicks on elements that are transitioning on/off screens, to prevent transparent elements that overlap clickable ones from getting in the way, etc

[14:24:51.0000] <zewt>
they're all things that can be worked around with varying levels of effort, but just setting pointer-events: none is so much quicker

[14:37:53.0000] <Wilto>
♡ pointer-events: none;

[14:37:59.0000] <Wilto>
Just sayin’.

[14:59:09.0000] <zewt>
nice to see a bit of support from MS on autoRevoke, since they seemed to be digging in their heels before

[15:02:47.0000] <tantek>
zewt, wilto, thanks - appreciated.

[15:03:15.0000] <tantek>
zewt, the specifics you provided are particularly helpful.

[15:09:10.0000] <tantek>
captured: http://wiki.csswg.org/spec/css4-ui#pointer-events

[15:20:02.0000] <zewt>
bleh, why is <label for> an ID; probably means I can't use them at all and need to implement it myself

[15:20:30.0000] <zewt>
(since I'm wholesale cloning multiple copies of something containing a <form>)

[15:37:28.0000] <zewt>
can't do dataset["a-b"] = "c"? :|

[15:38:29.0000] <zewt>
oh god, it doesn't *seriously* convert camel case

[15:39:05.0000] <zewt>
that's horrifying

[15:42:01.0000] <zewt>
i was concerned about it stripping data- (because it means I have to remember to strip "data-" when grepping for where [data-foo] is modified), but this is just obfuscation

[15:56:36.0000] <Hixie>
zewt: don't use the [] stuff, just use direct indexing, as in dataset.aB

[16:02:58.0000] <zewt>
that's no better, it still obfuscates my identifiers

[16:03:33.0000] <Hixie>
"obfuscates"?

[16:03:48.0000] <Hixie>
i'm not sure i understand what you're complaining about

[16:04:54.0000] <zewt>
if I have "[data-foo-bar=bar]" in CSS, i don't want to have to play games trying to figure out that I need to grep for "fooBar" to figure out where it's coming from

[16:05:33.0000] <tantek>
zewt - the alternative to <label for> is to use <label> to wrap the element it applies to e.g. <label><input/></label> - would that work in your case?

[16:08:01.0000] <zewt>
may take some style changes to make it work

[16:08:14.0000] <Hixie>
zewt: so use setAttribute

[16:08:39.0000] <Hixie>
zewt: (there's no need to play games, it's the same logic as is used for other IDL attributes)


2012-08-15
[23:09:16.0000] <zcorpan>
if the Team and the Director just want a Rec and don't care about interop, why not publish a Rec immediately and be done with it?

[23:12:10.0000] <jgraham>
zcorpan: AFAICT the process is changing slowly. State (1) was "require a full testsuite". State (2) is "look at caniuse.com". State (3) will be "publish immediately"

[23:18:11.0000] <zcorpan>
i have my doubts that the w3c and the html wg will allow themselves to publish immediately since that would waste minimal amount of time

[23:18:35.0000] <jgraham>
It's hard to say that not requiring a full testsuite is a bad thing. At least the incentives for creating a testsuite just to pass some formal process are perverse; ideally people would be creating tests to actually improve interoperability, and people fixing bugs would be free to pick and choose the most important issues to work on

[23:19:43.0000] <jgraham>
zcorpan: Well it took many years and CSS2.1 to get from stage (1) to "you have the choice of (1) or (2) but we're not doing (1)"

[23:20:07.0000] <jgraham>
Getting to stage (3) will probably not happen for a while yet :)

[23:20:56.0000] <jgraham>
(OTOH, it is possible that some parties will be less willing to contribute tests if there isn't a Process-based motivation)

[23:21:04.0000] <jgraham>
(which is sad)

[23:53:54.0000] <zcorpan>
jgraham: hmmmmmmm. shouldn't "stop parsing" provide a stable state so that the resource selection algorithm's sync section (which delays the load event) gets to run before "stop parsing" goes on to fire 'load'?

[00:01:49.0000] <zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18565

[00:26:49.0000] <jgraham>
Uh, maybe?

[00:27:13.0000] <jgraham>
The details of the resource selection algorithm are a horror I have managed to avoid

[00:36:53.0000] <jgraham>
Media events get their own task source?

[00:37:36.0000] <jgraham>
I feel like that's not going to work

[00:38:01.0000] <jgraham>
In particular the order relative to other DOM events being undefined

[00:38:05.0000] <jgraham>
Hixie: ^

[00:58:18.0000] <zcorpan>
yeah i don't know why it has that. i've kind of ignored task sources until recently

[00:58:37.0000] <zcorpan>
mind you not all media events use that task source

[01:00:01.0000] <zcorpan>
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#audiotracklist-and-videotracklist-objects says DOM manipulation

[01:00:34.0000] <zcorpan>
i'll file a bug

[01:02:19.0000] <zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18570

[01:19:04.0000] <zcorpan>
can unzipping be incremental (i.e. should the API support incrementally exposing of the files)?

[01:28:47.0000] <zcorpan>
html wg no longer requires the boilerplate of editors when resolving bugs?

[01:29:12.0000] <zcorpan>
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=17563#c10 )

[01:30:41.0000] <Ms2ger>
That was only to annoy Hixie, you didn't know?

[01:31:14.0000] <odinho>
^_^

[01:31:43.0000] <zcorpan>
it's just the canvas spec that has editors, right?

[01:37:22.0000] <Ms2ger>
Nah, HTML has a team too

[01:44:46.0000] <zcorpan>
ah

[01:47:38.0000] <jgraham>
Not to be confused with a Team

[01:48:06.0000] <jgraham>
Which would be MikeSmith and his accomplises

[01:55:34.0000] <odinho>
The W-Team!

[01:55:48.0000] <hsivonen>
w3cmemems needs a meme about relaxing the CR exit criteria

[01:56:09.0000] <odinho>
Yeah, was thinking about that, but can't figure out something cool.

[01:56:56.0000] <hsivonen>
Brace yourselves, fast-tracking the Process by relaxing CR exit criteria has begun.

[01:57:40.0000] <odinho>
that sure is a mouthful :P

[01:58:39.0000] <jgraham>
There is something very pleasing about writing tests that pop up windows and then have them automatically close them when the test is done

[02:00:08.0000] <odinho>
jgraham: Reviewed some tabs+windows extension tests, they did that a lot. Even crashed my window manager at one point.

[02:00:36.0000] <jgraham>
Heh

[02:01:57.0000] <jgraham>
So, when will gecko implement shared workers?

[02:13:12.0000] <Ms2ger>
jgraham, patches welcome :)

[02:16:17.0000] <jgraham>
:p

[02:16:49.0000] <Ms2ger>
Do you have someone who can look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=14421 ?

[02:20:24.0000] <jgraham>
Not sure who that would be, but I can ask

[02:52:43.0000] <zcorpan>
krijn logs down for good or temporarily?

[02:53:35.0000] <Ms2ger>
He's moved offices, and is working on getting them up again, AIUI

[02:59:27.0000] <Ms2ger>
MikeSmith, [tm], pulling from https://dvcs.w3.org/hg/webapps seems to be broken with a 500 Internal Server Error, plain HTTP works

[02:59:36.0000] <Ms2ger>
(Same for /html)

[04:43:11.0000] <zcorpan>
http://playcanvas.com/a-multiplayer-3rd-person-shooter-in-html5/ sounds awesome

[05:10:05.0000] <zcorpan>
http://www.alistapart.com/articles/love-the-boring-bits-of-css/ ...uh, i thought :matches() and :any() were different

[05:49:40.0000] <krijn>
zcorpan: what Ms2ger said, sorry for the delay

[05:50:05.0000] <zcorpan>
krijn: no worry, i was just curious

[06:43:51.0000] <Ms2ger>
jgraham, thanks for finding someone who knows about canvas :)

[06:44:09.0000] <jgraham>
Ms2ger: No problem :) We have gfx QA for a reason :)

[06:52:39.0000] <hsivonen>
How did http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html become a HTML WG doc?

[07:01:00.0000] <karlcow>
"Instead of referencing SVG files in your CSS or adding them as data URIs, you add the SVG markup right below the closing body tag and use Javascript to parse through them and generate CSS rules at runtime." — http://www.somerandomdude.com/2012/08/12/svg-css-injection/

[07:01:00.0000] <karlcow>
Parsing headaches ahead.

[07:01:19.0000] <zewt>
zcorpan: re ZIPs, you can incrementally access files in ZIPs if you have a streaming source, but since the source for this API is a Blob (rather than a URL) it's not

[07:01:57.0000] <zewt>
(ZIPs have both incremental file records, before each file data, and another central record at the end, so they support both streaming and fast random lookup)

[07:02:23.0000] <zewt>
(i've implemented ZIP APIs on three or four independent occasions, heh)

[07:03:12.0000] <zewt>
aside from the filename encoding thing (since the format is so old), it's actually not a bad format, surprisingly unhorrible for its age

[07:03:19.0000] <zewt>
afk

[07:06:12.0000] <Ms2ger>
Ah, W3C Management still as incompetent as ever

[07:38:57.0000] <jgraham>
Hmm, should testharness.js call completion_callback for tests that get the status NOT_RUN?

[07:39:14.0000] <jgraham>
I mean result_callback

[07:39:22.0000] <jgraham>
It doesn't but I tend to think it should

[07:40:47.0000] <Ms2ger>
Probably, yes

[07:42:14.0000] <Stevef_>
hsivonen: interesting to note that the issue of hiding info in title attributes was raised in that 2004 post you retweeted

[08:08:38.0000] <jgraham>
Ms2ger: Changed that

[08:15:10.0000] <odinho>
I feel so stupid when I always have a problem with remembering that stopPropagation is named just that. And doing that and preventDefault  is quite common.

[08:15:35.0000] <odinho>
They're quite a mouthful for a non-native speaker too :P

[08:15:53.0000] <odinho>
I write cancelPropagation often first.

[08:16:50.0000] <jgraham>
If it makes you feel better, there is no way I can spell "propagation"

[08:16:57.0000] <jgraham>
(I had to copy you there)

[08:17:03.0000] <jgraham>
(too many vowels)

[08:20:21.0000] <odinho>
sicking: There?

[08:21:59.0000] <jreading>
canvas

[08:22:41.0000] <odinho>
jgraham: It does makes me feel better. :-) Although not always that happy about js naming. :]

[08:24:32.0000] <odinho>
jreading: What? That's a bit too cryptic.

[08:25:40.0000] <jgraham>
odinho: Maybe that's jreading's password

[08:26:05.0000] <jreading>
ha, sorry wrong window

[08:26:35.0000] <jreading>
i came here for the css vars drama and very upset to not see any :)

[08:47:31.0000] <jgraham>
jreading: You want drama? Watch this: @srcset! @longdesc! FORMAL OBJECTION!

[08:47:43.0000] <jgraham>
Should be plenty of drama now :)

[08:48:08.0000] <Ms2ger>
That's the best you can do?

[08:48:22.0000] <jgraham>
I wasn't feeling very inspired

[08:48:25.0000] <jgraham>
Sorry

[08:48:41.0000] <jgraham>
But fortunately it doesn't take much :)

[08:48:50.0000] <Ms2ger>
Heh

[08:51:18.0000] <dglazkov>
good morning, FORMAL OBJECTION!

[08:51:25.0000] <dglazkov>
er, Whatwg!

[08:51:57.0000] <Ms2ger>
/me kicks dglazkov out again

[08:53:05.0000] <dglazkov>
can someone please start a ska band called Formal Objection?

[08:55:46.0000] <jgraham>
Maybe if we just got the frontperson to adopt the monkier "Formal Objection", they could team up with Bob Marley's backing band?

[08:58:30.0000] <dglazkov>
jgraham: count me as a fan already

[08:59:06.0000] <dglazkov>
/me takes out his iPhone, launches the Lighter app.

[09:03:04.0000] <hober>
jgraham: "Formal Objection and the Vendor Prefixes"?

[09:15:47.0000] <hsivonen>
whoa. chairs asking about support for a CP. (as opposed to objections)

[09:17:27.0000] <Ms2ger>
Also, anybody who likes prefixing discussions, I'll be in #css with the popcorn

[09:22:37.0000] <hober>
Ms2ger: you're lucky you aren't in the room! :)

[09:23:03.0000] <Ms2ger>
Very

[09:23:24.0000] <Ms2ger>
hober, do you expect anything new will be said?

[09:24:32.0000] <hober>
I doubt it, but I'm trying to be optimistic.

[09:27:24.0000] <smaug____>
jgraham: btw, do you happen to know if the spec says how http://mozilla.pettay.fi/moztests/history2/Start.html should behave?

[09:27:59.0000] <dglazkov>
excellent post from slightlyoff: http://infrequently.org/2012/08/inadmissible-arguments/

[09:28:09.0000] <dglazkov>
especially like the use cases bit

[09:30:42.0000] <smaug____>
hmm, perhaps the spec is clear there

[09:30:57.0000] <smaug____>
well, not clear, but defines

[09:31:04.0000] <smaug____>
and Gecko/IE behavior is correct

[09:49:36.0000] <sicking>
odinho: yes

[09:49:55.0000] <jgraham>
smaug____: Without reading the spec, I am unclear why each iframe wouldn't appear in the session history

[09:50:41.0000] <odinho>
sicking: Been looking at this IDB bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=18551

[09:51:07.0000] <odinho>
sicking: And wrote a few tests of how I think it should be. And I think Firefox actually passes them all :P

[09:51:26.0000] <sicking>
woot :)

[09:51:49.0000] <sicking>
odinho: bent writes good code :)

[09:53:04.0000] <odinho>
I had a question but I figured it out. So I think that also makes a strong case for how to solve 18551. I think Opera will also behave like that when an abort bug is fixed.

[09:54:34.0000] <smaug____>
jgraham: because they are removed from the document

[09:55:40.0000] <sicking>
odinho: sweet

[09:58:56.0000] <jgraham>
smaug____: Ah! Clever!

[09:59:19.0000] <jgraham>
smaug____: And now I know what I will write tests for tomorrow! With spec-compliant pass conditions and all!

[10:00:23.0000] <jgraham>
(that was worth four exclaimation marks! and two meta-exclaimation marks!)

[10:01:33.0000] <odinho>
sicking: But ... about that email I wrote that noone wanted to touch with a fire pole...

[10:02:12.0000] <odinho>
sicking: The strange behaviour of opening new databases and it hanging forever.

[10:02:18.0000] <odinho>
sicking: (or deleting)

[10:02:56.0000] <sicking>
i don't recall that one

[10:03:06.0000] <sicking>
/me heads in to meeting

[10:04:02.0000] <odinho>
Hmm. I actually got replies which I seem to have read on my phone, so they didn't come up here. :P

[10:04:16.0000] <odinho>
Will continue thread then, -- since I got replies.

[10:06:25.0000] <jsbell>
odinho: chrome might behave as suggested in 18551 already too (give your tests a whirl on Chrome?) - we brought it up when we realized the async create/delete behavior we had fell out of the implementation rather than being defined by the spec.

[10:06:57.0000] <odinho>
jsbell: Well, I'm always put off by the setVersion() thing. Do you have a build with newer API?

[10:07:26.0000] <jsbell>
odinho: crud, sorry. Coming in a Canary build in the next few days.

[10:07:29.0000] <odinho>
I should possibly look into polyfilling the tests just to check stuff like that. But it has to be in a common file then, because it's way too ugly to stand :P

[10:07:43.0000] <jsbell>
I have a polyfill somewhere, let me post it...

[10:08:29.0000] <odinho>
I prolly have to port it a bit, but just looking at another one will speed it up.

[10:08:50.0000] <odinho>
jsbell: Great news about canary btw. How much is fixed?

[10:09:33.0000] <jsbell>
odinho: https://gist.github.com/3361666

[10:09:44.0000] <odinho>
jsbell: I am fighting with mercurial in order to put up my tests as of now, btw.

[10:09:54.0000] <odinho>
I have not commited to it in a few weeks.

[10:10:19.0000] <odinho>
Only to my Opera git-backed repo :]

[10:10:46.0000] <jsbell>
odinho: Chrome will support open(name, version) and fire upgradeneeded events. We'll also support setVersion() for a while (while prefixed) so we don't break some deployed sites.

[10:11:09.0000] <jsbell>
This leads to a few wrinkles around open(name) (no version) and upgradeneeded that we still need to sort out.

[10:12:36.0000] <jsbell>
Other than that, firing blocked events too early, and no Blob support, and no Sync API (though we do have Async API for workers) I believe we've got everything implemented.

[10:13:36.0000] <odinho>
jsbell: Cool, will run my tests on it straight away when there's a build.

[10:13:45.0000] <odinho>
Well, noone has sync :P

[10:13:54.0000] <jsbell>
Yeah, just being pedantic :)

[10:17:06.0000] <jgraham>
odinho: Go all github on their asses ;)

[10:17:36.0000] <odinho>
jgraham: Well, I like it that hg push also puts the files on w3c-test.org

[10:17:58.0000] <Ms2ger>
Bah, github

[10:40:04.0000] <Hixie>
jgraham: the media systems are expected to be on a different thread and thus unable to coordinate with other things for ordering of events

[10:51:18.0000] <jgraham>
Hixie: That makes sense, but it strikes fear into my heart

[10:51:44.0000] <jgraham>
Pages will depend on the relative order of e.g. the load event and various media events

[10:54:31.0000] <othermaciej>
for anyone who's interested in W3C process for HTML5 (maybe not most folks here), I recommend looking at this thread about CR exit criteria http://lists.w3.org/Archives/Public/public-html/2012Aug/0190.html

[10:54:55.0000] <othermaciej>
short version is that there's some tension between testing interop in detail, and getting to REC fast

[10:55:10.0000] <othermaciej>
I would be particularly interested in implementor input since that's likely the group most impacted

[10:56:01.0000] <jamesr>
othermaciej, i saw that and was curious about the W3C consequences of getting to REC faster

[10:56:02.0000] <jamesr>
seems like the lax version is somewhat SVG2-ish - just public a big old document with no conformance requirements or checks

[10:56:02.0000] <jamesr>
and i don't know who benefits from that

[10:56:36.0000] <othermaciej>
jamesr: the way I see it (and maybe I should say this on the thread) is that REC has three purposes:

[10:56:48.0000] <othermaciej>
(1) declare to the world that the spec is "done"

[10:56:58.0000] <othermaciej>
(2) cause patent commitments to officially take effect

[10:57:22.0000] <othermaciej>
(3) drive creation of a test suite and convergence of the spec and implementations on interoperable behavior

[10:57:34.0000] <jamesr>
the lax version seems to mostly throw away (3)

[10:57:42.0000] <othermaciej>
I think the W3C Process would be better if (1) and (2) were separated from (3)

[10:57:59.0000] <othermaciej>
yes, the lax version skimps on (3), the strict version delays (1) and (2)

[10:58:08.0000] <Hixie>
jgraham: it's a risk, certainly

[10:58:21.0000] <Hixie>
jgraham: but that's a risk anywhere we have multiple event sources

[10:58:47.0000] <Hixie>
othermaciej: if we want to do (1) and (2) quickly, why bother with a CR at all? just publish a REC

[10:59:09.0000] <Hixie>
othermaciej: (which is what i'd been proposing for months and would have avoided all this forking nonsense)

[10:59:19.0000] <othermaciej>
Hixie: I think the W3C Process requires a minimum duration of CR, but given that, the "loose" criteria would basically have that effect

[10:59:26.0000] <jamesr>
othermaciej, as someone who's job description doesn't include woring about (2), (3) is the most important thing so the lax version seems silly. but i suspect in the broader picture (2) and to a lesser degree (1) are pretty important so i'd say REC tomorrow

[10:59:33.0000] <Hixie>
othermaciej: the process requires lots of stuff the w3c ignores

[10:59:34.0000] <jamesr>
s/woring/worrying/ (not whoring)

[10:59:38.0000] <othermaciej>
Hixie: since you would go into CR having already met all the exit criteria other than time

[10:59:44.0000] <Hixie>
othermaciej: if the process means anything, then it should be followed in spirit, and not have a loose CR

[10:59:57.0000] <Hixie>
(there's no minimum time for CR)

[10:59:58.0000] <jamesr>
the waiting period is what, 60 days? something like that?

[11:00:05.0000] <othermaciej>
jamesr: I'd love to have that input on the thread

[11:00:26.0000] <jgraham>
Hixie: Yes, in general each time we introduce a task source we introduce the possibility of race conditions. That seems like something we want to minimise

[11:00:47.0000] <Hixie>
jgraham: it's a balancing act, certainly

[11:01:00.0000] <othermaciej>
jamesr: in my dreams, what the W3C would do is rename CR to "Recommendation", rename "Recommendation" to "Standard", move patent commitments to what was CR and would be REC, and leave comprehensive interop proof at the STD level

[11:01:16.0000] <othermaciej>
jamesr: and STD would be considered an optional step that only the most critical and widely deployed specs ever reach

[11:01:50.0000] <jgraham>
/me would advise not using the acronym STD :)

[11:02:03.0000] <odinho>
:-)

[11:02:22.0000] <othermaciej>
the ietf has already been down that road, and there is a surprising lack of mockery

[11:02:55.0000] <jgraham>
In my dreams the W3C would move to a WHATWG-like model where IPR commitments were based on strictly date based snapshots and the spec evolution was continuous

[11:03:01.0000] <Hixie>
(if we're allowed to dream, then in my dreams, patents wouldn't apply to software, and we'd use a living standard model and people who need a fixed reference point would use revision numbers)

[11:03:32.0000] <Hixie>
(but i'm guessing we're not really allowed to dream :-P)

[11:03:33.0000] <odinho>
Such a dream, should do a speech

[11:03:37.0000] <jgraham>
And the testsuite would be developed along with the spec by people interested in interoperability rather than people intreseted in fulfilling Process requirements

[11:03:38.0000] <jamesr>
othermaciej, i don't think i'll post on the thread, mostly because i can't tell what on earth most of the people on public-html are trying to do. just seems like a crazy flamewar land

[11:03:58.0000] <gavinc>
A most excellent paper on software patents: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2117302

[11:06:16.0000] <othermaciej>
jgraham: I think evidence so far is that whatwg model does not result in a comprehensive test suite at all

[11:06:47.0000] <othermaciej>
this may be a sign of the market not finding it worth doing, or it could be a collective action problem

[11:07:04.0000] <Hixie>
well the whatwg model on the test suite front has been "people are making a test suite at the w3c, so let's avoid duplicating effort"

[11:07:09.0000] <Ms2ger>
othermaciej, dunno if you noticed, but the vast majority of tests in the HTMLWG test suite were written by people in this channel

[11:07:11.0000] <jamesr>
i'm not sure what model does lead to a comprehensive test suite

[11:07:16.0000] <jamesr>
i would love to see it

[11:07:26.0000] <othermaciej>
CSS2.1 managed to have a comprehensive test suite

[11:07:30.0000] <jamesr>
!

[11:07:34.0000] <othermaciej>
but it took 5-6 years from entry to CR

[11:07:41.0000] <othermaciej>
well, fairly comprehensive

[11:07:50.0000] <jamesr>
how can it be comprehensive when the spec itself leaves vast swaths undefined?

[11:07:59.0000] <Hixie>
(bbiab.)

[11:08:00.0000] <Ms2ger>
CSS2.1 doesn't have anything near a comprehensive test suite

[11:08:22.0000] <Ms2ger>
It's got something better than CSS2, that's about the best thing you can say about it

[11:08:38.0000] <jgraham>
othermaciej: The W3C model doesn't either

[11:08:52.0000] <othermaciej>
I think I'd probably claim that it's the most comprehensive test suite for any core web standard of similar complexity

[11:08:58.0000] <jgraham>
And making the testsuite a Process criterion sets all sorts of perverse incentives

[11:09:05.0000] <Ms2ger>
Maybe

[11:09:19.0000] <jgraham>
I... I actually don't think that is true

[11:09:27.0000] <othermaciej>
what's the counter-example?

[11:09:29.0000] <Ms2ger>
But "most comprehensive" doesn't imply "comprehensive", even if it is

[11:09:49.0000] <jgraham>
At least, I don't think that our internal testsuite for CSS 2.1 is better than our testsuite for other things

[11:09:58.0000] <othermaciej>
I accept that it's valid to claim it is not comprehensive enough

[11:09:59.0000] <jgraham>
s/internal//

[11:10:26.0000] <jgraham>
I mean I think the Opera-internal-ought-to-be-released drag and drop testsuite might be better

[11:10:26.0000] <othermaciej>
ok, "most comprehensive public cross-browser test suite for any core web standard of similar complexity"

[11:10:44.0000] <jgraham>
I think the 2D API testsuite might be better

[11:10:54.0000] <jamesr>
philip's canvas suite?

[11:10:54.0000] <othermaciej>
I don't think I would agree that just drag & drop or just 2D API is of similar complexity to CSS

[11:11:03.0000] <Ms2ger>
It probably is

[11:11:06.0000] <jgraham>
Sure, these are patchy things

[11:11:18.0000] <othermaciej>
I would agree that all of HTML is of greater complexity, and all of SVG is of similar complexity

[11:11:25.0000] <jgraham>
AryehGregor's DOM Range testsuite

[11:11:27.0000] <othermaciej>
and perhaps all of DOM, at least as DOM4 scopes it

[11:12:06.0000] <othermaciej>
just DOM Range? probably not, it's a tiny corner of the platform (though one with many edge cases)

[11:12:21.0000] <jgraham>
My point is that for the things where people have invested serious effort in testing that are not CSS the testsuites are often better than the CSS2.1 testsuite despite the lack of a strong Process driver

[11:12:45.0000] <jgraham>
othermaciej: I am not claiming that these things individually are better than the whole CSS2.1 testsuite

[11:12:49.0000] <othermaciej>
true, so it might be that the market does not believe most aspects of HTML do not need a serious test suite

[11:13:29.0000] <jgraham>
It might be that we haven't done enough to encourage people to submit the tests that they are writing anyway

[11:14:01.0000] <jamesr>
one strong motivation for building a good test suite is you want to create a new implementation, and i think nobody is attempting that for HTML

[11:14:03.0000] <jgraham>
e.g. WebKit contributers have not -- in general -- been a great source of public tests

[11:14:12.0000] <jgraham>
But I assume you *have* tests

[11:14:16.0000] <Ms2ger>
Neither have we, to be fair

[11:14:44.0000] <jgraham>
We haven't been as good as I would like (see comment about drag and drop)

[11:14:45.0000] <Ms2ger>
(I think most of the WebGL test suite came from WebKit, though)

[11:15:06.0000] <jamesr>
Ms2ger, an example of writing a test suite to pull up an implementation

[11:15:12.0000] <Ms2ger>
At least, they use the same horrendous test harness

[11:15:16.0000] <othermaciej>
well, we have a lot of public tests, but most are not designed to be good cross-browser standards tests

[11:15:19.0000] <jamesr>
if you already have something big that a bunch of people sort of do, it's harder to bother

[11:15:40.0000] <jgraham>
jamesr: There are so many areas that have really crappy interop

[11:15:48.0000] <jgraham>
and people bugfix those areas

[11:15:51.0000] <Ms2ger>
Heh

[11:16:01.0000] <Ms2ger>
Are there areas that don't have really crappy interop?

[11:16:26.0000] <jgraham>
and they aren't in the mindset of "I should contribute this test I wrote to verify the behaviour matches the spec and the spec matches what's needed"

[11:16:47.0000] <jgraham>
See, for example, smaug____'s history navigation test from earlier

[11:17:11.0000] <jgraham>
4 implementations, 3 behaviours, spec matches 2 implementations, no tests

[11:17:19.0000] <othermaciej>
at times, WebKit contributors would prefer to modify our local copies of imported standards test suites than to make the desired changes upstream

[11:17:44.0000] <jgraham>
Also, lots and lots of things are greenfield developments e.g. IndexedDB

[11:17:49.0000] <othermaciej>
I try to encourage people to do the fixes upstream when possible, but that's not always an easy sell

[11:18:30.0000] <jgraham>
othermaciej: Making that an easy sell seems vastly more important to me than what the HTMLWG Process is

[11:18:46.0000] <Ms2ger>
I just tell them I'll overwrite their changes next time I import some tests

[11:20:07.0000] <jgraham>
(of course it depends what the reason is whether I can do anything about it. If the reasoning is "I think we should kep our tests proprietary to screw over the other vendors", there's not much I can do to help)

[11:21:09.0000] <jgraham>
(but if it's more like "the process for uploading them is a bit tedious", there might be a technical solution)

[11:21:54.0000] <othermaciej>
webkit tests are all in a public repository under a liberal license, so it's definitely not a question of keeping them proprietary

[11:22:10.0000] <othermaciej>
just lack of desire to expend greater effort and wait longer for results

[11:22:44.0000] <othermaciej>
(at least, I don't believe Apple has secret proprietary correctness tests for WebKit, and I doubt other vendors do either)

[11:24:46.0000] <smaug____>
jgraham: sorry about not uploading those tests to anywhere

[11:24:55.0000] <smaug____>
(although, those tests are old)

[11:25:03.0000] <jgraham>
"proprietary" might be the wrong word. Someone could have an attitude of "why should I do something that will help other vendors" even when the stuff is in a public repo. because it is much less likely that someone will comb through all your tests looking for ones that are valuable than it is that someone will use a test posted to a shared repo.

[11:25:08.0000] <smaug____>
(and I don't know where I could upload the tests)

[11:25:30.0000] <jgraham>
smaug____: I didn't mean to single you out, except to point out that you wrote some useful tests :)

[11:26:11.0000] <jgraham>
If you wanted to upload them they would go in the W3C html test repository which is dvcs.w3.org/hg/html

[11:26:25.0000] <othermaciej>
it's more like "I'm trying to fix this specific problem right now, and it's not worth it to me to expend extra effort and wait longer"

[11:26:31.0000] <smaug____>
you can blame me :) I was testing session history quite a bit when I changed Gecko's implementation to behave more like IE

[11:27:04.0000] <jgraham>
smaug____: But in the specific case that you linked I will write some automated tests using the standard harness

[11:27:18.0000] <jgraham>
So if you have more similar tests email me a link or something

[11:27:33.0000] <jgraham>
othermaciej: Right. I understand that but I don't really know what to do about it

[11:27:56.0000] <smaug____>
jgraham: if I had some tests using the standard harness, where should I upload them?

[11:28:50.0000] <othermaciej>
I think having a person where part of their job responsibility is to upstream tests to standards groups might help

[11:29:03.0000] <jgraham>
smaug____: http://dvcs.w3.org/hg/html under /tests/submission/Mozilla

[11:29:42.0000] <smaug____>
I wonder if I have access to that one

[11:30:09.0000] <jgraham>
othermaciej: Right. It works sort of OK at Opera because we have more people in dedicated QA roles

[11:30:22.0000] <smaug____>
would I need to be member of html wg? (which I certainly don't want to be)

[11:30:39.0000] <jgraham>
And I (plus others) have pushed for "submt tests to W3C" to become a normal part of that job

[11:30:48.0000] <jgraham>
Although we don't always achieve it

[11:30:56.0000] <othermaciej>
speaking of which, Apple is hiring for various roles where creating tests and submitting tests to standards groups would be part of the job

[11:31:06.0000] <jgraham>
smaug____: I think you would need to be

[11:31:15.0000] <othermaciej>
not reporting to me personally, but if anyone wants to do that sort of thing, or has a good person to refer, let me know

[11:31:53.0000] <jgraham>
smaug____: Lots of paranoia from certain parties that someone might slip something into the repo without agreeing to the CLA

[11:32:53.0000] <jgraham>
smaug____: But I guess you can always ask me or Ms2ger or hsivonen or someone to commit for you

[11:33:16.0000] <smaug____>
k

[11:33:43.0000] <Ms2ger>
I'm not in the HTMLWG, and I have access

[11:34:26.0000] <Ms2ger>
Not sure what the exact requirements are, MikeSmith might know

[11:34:39.0000] <jgraham>
Maybe you just have to agree to the licensing thing

[11:34:48.0000] <Ms2ger>
But yes, feel free to throw any tests at me

[11:34:52.0000] <jgraham>
I will try to find it on one of the 26 different wikis

[11:35:05.0000] <Ms2ger>
Using testharness.js is nice, but not required ;)

[11:36:42.0000] <jgraham>
smaug____: Oh, it looks like you might have access as long as you have some kind of W3C account with Mozilla listed as your employer

[11:37:10.0000] <jgraham>
I think it used to be WG members only but now isn't

[11:38:55.0000] <smaug____>
k

[11:51:45.0000] <jgraham>
(to return to an earlier point, I am pretty sure that in other WGs I have seen people suggest removing tests that touch on tricky or underdefined behaviour so they could get to Rec. without fixing implemenations / the spec)

[14:19:57.0000] <tantek>
jgraham that has indeed happened, and CSS 2.1 is an example.

[14:21:08.0000] <tantek>
though in those cases the  tests that touch on tricky or underdefined behavior were captured for specifying in the respective CSS3 modules. Once done so, I could easily see those kinds of bug fixes working their way into errata.

[14:57:27.0000] <Hixie>
wtf

[14:57:42.0000] <Hixie>
all the bugs filed from "User agent: Mozilla/5.0 (BlackBerry [...]" are bogus

[14:57:56.0000] <Hixie>
7 now, over the last year

[14:58:47.0000] <Hixie>
make that 12


2012-08-16
[17:15:59.0000] <a-ja>
someone mess with mime types on tracker ?

[17:16:54.0000] <a-ja>
vendor icons appear to be borked

[18:05:10.0000] <zewt>
heh, are people still holding their breath expecting history api to make hash urls go away

[18:05:30.0000] <Hixie>
you mean pushState()?

[18:05:52.0000] <zewt>
because i've found it seriously convenient that I can say <a href=#profile> and have it hook into onpopstate without having to do anything else to the link

[18:06:00.0000] <Hixie>
pushState() won't be used to make fragids disappear except for cases where the server knows how to generate pages for each url (e.g. how g+ does)

[18:06:50.0000] <zewt>
yeah, but at least earlier on people were going "finally! now evil hash urls can die!" which just isn't going to happen

[18:07:15.0000] <zewt>
(not that you don't know this :)

[18:08:13.0000] <Hixie>
what's wrong with fragids when all the parts are defined in the page?

[18:08:59.0000] <zewt>
i say nothing's wrong with it, some people seemed on the religious side in claiming they should only ever be used for their original purpose (which I found a bit silly)

[18:09:25.0000] <mkanat_>
Well, it does make server-side analysis more difficult if you're looking at web logs.

[18:09:39.0000] <zewt>
i guess that'll always happen whenever something old is repurposed to do something new

[18:13:34.0000] <Hixie>
mkanat_: that's gonna happen regardless if you don't hit the server ;-)

[18:14:32.0000] <Hixie>
btw can anyone explain to me what all the fuss over app.net is? i can't work out what it does that's useful.

[18:14:36.0000] <mkanat_>
Hixie: Yeah, that's true. :-)

[18:14:51.0000] <zewt>
it's a three-letter domain, it's got to be useful! (no idea)

[18:21:11.0000] <zewt>
rather not nice that the spec allows ignoring pushState for non-user-actions

[18:21:38.0000] <zewt>
would break some of my own stuff if they actually did that

[18:25:29.0000] <Hixie>
the alternative is that pages could stuff the history with a thousand BS entries

[18:26:11.0000] <zewt>
not if implementations limit the number of history entries per document

[18:26:26.0000] <zewt>
it'd just cycle out old ones, without breaking things depending on the new one happening

[18:26:35.0000] <Hixie>
as a user i'd rather hate that

[18:27:45.0000] <zewt>
i have pages that eg. show a login prompt, on click send an XHR login request, and don't pushState until the login request succeeds

[18:27:59.0000] <zewt>
which could be outside the "user interaction" threshold, depending on the heuristic

[18:29:32.0000] <Hixie>
you should push on the login button click, so that if the user reloads while it's logging in, it still tries to login

[18:29:43.0000] <Hixie>
same as with a regular form load

[18:30:00.0000] <zewt>
the new state has nothing to do with login

[18:30:41.0000] <zewt>
(if I want to make that work I'd replaceState before the request to store the "sending a request" status, but I'd keep it in the same overall "showing the login page" state)

[18:33:18.0000] <zewt>
(doing it the other way just doesn't fit the rest of the stuff the site has built around history)

[18:41:26.0000] <Hixie>
sounds like a weird setup

[18:45:16.0000] <zewt>
seems natural to me :)

[18:45:31.0000] <Hixie>
hopefully authors don't abuse it and you'll not have to worry :-)

[18:48:52.0000] <zewt>
if browsers decide to be obnoxious i'll probably just sidestep it by using replaceState in the instances that do that; at least for login forms it's probably okay anyway (since going back to the login page when logged in will redirect elsewhere anyway)

[18:50:36.0000] <zewt>
but it's not great to have to worry about web apis that might some day lose interop and break sites

[18:51:00.0000] <Hixie>
yeah using pushstate and then replacestate later seems like the best option

[18:51:11.0000] <Hixie>
all apis have the risk of breaking

[18:51:29.0000] <Hixie>
all it takes is that the pressures to have some other behaviour be higher than the pressure to keep the current one

[18:51:37.0000] <Hixie>
e.g. a browser ships broken behaviour that a big site depends on

[18:51:55.0000] <zewt>
that's very far from the breakage being designed in from the outset :)

[18:52:18.0000] <Hixie>
use replaceState, it seems better to me in all ways :-)

[19:12:37.0000] <zewt>
event.state and history.state ever being different at the start of onpopstate is a bug, right?

[19:14:33.0000] <zewt>
damn, firefox gets confused if you replaceState from within onpopstate

[19:34:24.0000] <zewt>
heh, managed to make a decent guess of whether onpopstate is a forward or back ... but the code triggers history bugs in both webkit and ff

[19:38:31.0000] <Hixie>
oh i remember why we don't tell you if it's back or forward

[19:38:34.0000] <Hixie>
it can be both at the same time

[19:38:46.0000] <zewt>
another spec question--should clicking <a href=#a> repeatedly cause onpopstate each time, or only if it actually changes the hash? (webkit does, firefox doesn't)

[19:38:59.0000] <Hixie>
e.g. if you are in state 3 of 9, then the user jumps to the next page entirely in the history, and then goes back to state 6 of 9 in your app

[19:39:07.0000] <Hixie>
you just see a popstate for state 6 while in state 3

[19:39:10.0000] <Hixie>
but the user went back

[19:39:38.0000] <Hixie>
dunno off-hand, you'd have to see the spec

[19:39:49.0000] <Hixie>
pretty sure that's unambiguously defined though

[19:40:05.0000] <zewt>
my particular use case only really cares about in-document navigation; i have some code that sticks a sequence in the history state and (browser bugs aside) seems to at least make a usable guess

[19:40:25.0000] <zewt>
afk, food

[20:11:23.0000] <zewt>
sigh, history bugs in opera too (onpopstate isn't fired at all on <a href=#foo>)

[20:11:36.0000] <zewt>
discouraging to hit three bugs in three browsers in one night

[20:19:34.0000] <zewt>
hmm, could be two bugs in webkit rather than one in firefox and one in webkit (looks like the onpopstate that happens on initial load should happen before scripts run, so it's not actually visible)

[23:24:25.0000] <jgraham>
zewt: Got testcases (not even real ones, just things I could turn into real testcases)?

[23:24:41.0000] <jgraham>
Not just for the Opera bug, also for the Gecko + WebKit bugs

[00:54:22.0000] <odinho>
Someone is constantly breaking the formal objection thread. It's really irritating, it's not like I really want to read that thread anyway, although I find it a bit interesting at times, but when it keeps breaking all over the place and take lots of space it irritates me. Hrmf

[00:55:49.0000] <odinho>
I think it is apple's mail client, because it's David Singer, Maciej Stachowiak who have broken it. And also John Foliot keeps doing it.

[00:56:01.0000] <odinho>
Hmm, Benjamin Hawkes-Lewis once as well.

[00:58:14.0000] <odinho>
Hmm, it's because the discussion is going over several lists.

[00:58:41.0000] <odinho>
Hmmm, my email client should get a better and less strict threading algo I guess.

[01:59:01.0000] <AryehGregor>
Ms2ger, jgraham, etc.: I think I'm going to make a post now to dev.platform requesting that Mozilla institute a new policy saying that for all bugs where behavior is covered by a standard, we make it mandatory that the test is written in testharness.js format and put in a special directory in m-c for tests to be submitted.

[01:59:14.0000] <AryehGregor>
Rather than with regular mochitests.

[01:59:21.0000] <Ms2ger>
Sounds good to me :)

[01:59:21.0000] <AryehGregor>
Then Ms2ger or I or someone can periodically look through all such tests and submit them to the right places.

[01:59:46.0000] <jgraham>
AryehGregor: If you get that through I will hero worship you

[01:59:53.0000] <jgraham>
At least for a short while

[02:00:06.0000] <AryehGregor>
I mean, I've fixed bugs regularly that were relevant to standards, but I would always just write the tests in our standard mochitest format, because that was just regular procedure.

[02:22:42.0000] <jgraham>
Right, we are relatively good at writing *testsuites* as testharness.js tests and relatively bad at writing one-off testcases as testharness.js tests (and worse at contributing them)

[02:22:52.0000] <jgraham>
So we have room to improve for sure

[02:23:27.0000] <jgraham>
Maybe I could grep the test repo for testharness.js tests that haven't been submitted or something

[02:31:09.0000] <AryehGregor>
jgraham, https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/AUJaVnuGFKI%5B1-25%5D

[02:36:23.0000] <jgraham>
AryehGregor: That sounds both pragmatic and hugely beneficial to the web to me. I hope that others agree :)

[02:39:25.0000] <AryehGregor>
/me restarts to install shiny new SSDs

[02:40:22.0000] <hsivonen>
are testharness.js tests as easy to write as mochitests these days?

[02:40:31.0000] <hsivonen>
can I do

[02:40:44.0000] <hsivonen>
start(); is(...); finish();

[02:40:52.0000] <hsivonen>
do I need more boilerplate?

[02:41:26.0000] <Ms2ger>
You don't need start() and finish(), just test(function() { // asserts });

[02:41:27.0000] <jgraham>
The minimal test is something like test(function() {assert_true(true)})

[02:41:47.0000] <hsivonen>
ok. so still harder to grok :-(

[02:43:24.0000] <hsivonen>
what if asserts need to be spead over a bunch of event queue tasks?

[02:43:33.0000] <jgraham>
Well all I can say is that the API complaints have all come from people that haven't used it

[02:43:48.0000] <jgraham>
Which doesn't mean it's perfect of course

[02:44:02.0000] <hsivonen>
I've tried it twice

[02:44:06.0000] <jgraham>
But you may be making a bigger deal of this than it actually warrants

[02:44:16.0000] <hsivonen>
ok

[02:45:12.0000] <jgraham>
For tests that are async you do var t = async_test(); t.step(function(){}); t.done()

[02:45:31.0000] <Ms2ger>
Well, async tests are somewhat harder, that's true

[02:47:33.0000] <jgraham>
Personally I usually find it takes much longer to work out what the right behaviour to test is than it does to type the boilerplate

[02:47:52.0000] <Ms2ger>
You're used to the boilerplate :)

[02:48:10.0000] <jgraham>
But yes, I agree that this is one area in which compromises were made in the design

[02:48:20.0000] <Ms2ger>
I don't think it's terribly hard, but it takes some getting used to

[02:49:42.0000] <Ms2ger>
And because mochitests have always used window.onerror, wrapping everything in functions looks somewhat foreign

[02:51:01.0000] <jgraham>
Make the JS people add macros, then you have have a shorter syntax and the same properties ;)

[02:51:30.0000] <Ms2ger>
Heh

[02:51:31.0000] <odinho>
if I write tsf<tab> it becomes   t.step_func(function(e) {<cursor>});    and   ts<tab> becomes  t.step(function() {<cursor>});

[02:51:56.0000] <jgraham>
odinho: That's pretty cool

[02:52:05.0000] <Ms2ger>
What do you use?

[02:52:09.0000] <odinho>
vim

[02:52:50.0000] <Ms2ger>
Ugh :)

[02:53:12.0000] <odinho>
Ms2ger: It's possible in almost all editors :P

[02:56:02.0000] <jgraham>
odinho: Dammit now you nerd-sniped me into working out how to do it in yasnippet mode in emacs :)

[02:56:47.0000] <odinho>
jgraham: lol. nerd-sniping :D

[02:57:49.0000] <odinho>
I was actually thinking of changing/add another one for  this.step_func(function(e) {})  I've found that I sometimes like to write tests like that, not having any variables pointing to the async test.

[02:59:40.0000] <odinho>
Then I just do.    async_test(document.title + " - doThis").step(function() { doThis().onsuccess = this.step_func(function() { assert_true(bla); }); })

[05:04:53.0000] <odinho>
I like your email AryehGregor :]

[05:05:01.0000] <AryehGregor>
odinho, which, to public-html?

[05:05:20.0000] <odinho>
AryehGregor: Yea, meant that, although the test-one to Mozilla as well though ;-)

[05:05:55.0000] <odinho>
s/ though//

[05:06:36.0000] <Ms2ger>
You read public-html?

[05:06:54.0000] <odinho>
Oh shi-, my dirty secret revealed!

[05:07:24.0000] <odinho>
What will people think of me now? :-S

[05:09:25.0000] <AryehGregor>
I don't, generally, but I saw the subject line about moving to REC and thought it was significant enough to look at.

[05:10:30.0000] <Ms2ger>
I would have the exact opposite reaction :)

[05:11:11.0000] <jgraham>
AryehGregor: +1 both to your message and to your public-html policy :)

[05:11:35.0000] <jgraham>
Although I think that bz has a point that Microsoft will stop contributing tests

[05:11:54.0000] <Ms2ger>
Then again, have you looked at their tests?

[05:11:59.0000] <AryehGregor>
Doubtful.  They contribute tests mostly so they look good, don't they?

[05:12:01.0000] <AryehGregor>
Also, yeah.

[05:12:30.0000] <Ms2ger>
The quality of their tests is at the same level as the quality of their spec feedback

[05:12:32.0000] <odinho>
Oh, I haven't said this here yet.

[05:12:52.0000] <odinho>
I rewrote the MS idb testsuite, and now IE is at 40% pass(!) (from being at 100%).

[05:12:55.0000] <odinho>
lol

[05:13:02.0000] <Ms2ger>
Heh

[05:13:31.0000] <jgraham>
Yeah, but there is some value in them submitting a testsuite for you to start from

[05:13:37.0000] <jgraham>
Even if it needed work

[05:13:42.0000] <odinho>
Yes, it was great.

[05:14:09.0000] <odinho>
I'm not good at getting a super big assignment and start working. I'm just sitting there being overwhelmed and unable to start :P

[05:14:39.0000] <odinho>
Now I could just go through their list of tests with assertions, and make sure it followed spec.

[05:16:55.0000] <zcorpan>
odinho: just pretend that you have an invisible list of tests with assertions, then make sure it follows spec, but then make the tests and assertions as you go :-)

[05:17:21.0000] <Ms2ger>
What do you guys think of an assert_class_name() that checks {}.toString.call(object) === "[object Class]"?

[05:17:31.0000] <odinho>
zcorpan: You so have to give me a master class

[05:18:14.0000] <jgraham>
Ms2ger: For Chekcing [[Class]]

[05:18:17.0000] <Ms2ger>
Also, did someone move  DSK-372132 already?

[05:18:17.0000] <jgraham>
*checking

[05:18:41.0000] <jgraham>
I suppose it's not a bad idea, but I wouldn't call it class_name

[05:18:42.0000] <odinho>
Ms2ger: I have a few  assert_equals(""+object, "[object Class]", "object is Class")  that could be replaced, -- but is there more to it? And is it very common?

[05:18:49.0000] <Ms2ger>
Well, WebIDL calls it a "class string" now

[05:19:03.0000] <jgraham>
Seems like it could be part of idlharness.js?

[05:19:32.0000] <Ms2ger>
idlharness has a lot of those, but I think I've wanted to use it in another test too

[05:19:49.0000] <Ms2ger>
odinho, that doesn't work if there's a stringifier somewhere, btw

[05:19:56.0000] <jgraham>
assert_class_string soulds fine to me

[05:21:51.0000] <zcorpan>
Ms2ger: here's a secret: navigating to https://bugs.opera.com/browse/DSK-372132 will redirect to the new bug if it has been moved even if you're not logged in

[05:22:16.0000] <Ms2ger>
Ah, yes, I seem to remember someone mentioned that

[05:22:17.0000] <zcorpan>
(i think matjas noticed that one)

[05:23:38.0000] <odinho>
Hmm. It's an API still though, so I don't think we should add stuff to it too lightly. It has to be maintained, it's extra documentation, making the whole thing more complex. It has to have some real benefits. :-)

[05:24:15.0000] <odinho>
Ms2ger: So, yes, it's been moved to core. And I can tell you relevant people is on CC list.

[05:24:23.0000] <Ms2ger>
Thanks :)

[05:26:50.0000] <Ms2ger>
Oh hey, Baidu's submitted a few tests

[05:27:01.0000] <jgraham>
odinho: Not really :p

[05:27:35.0000] <odinho>
jgraham: Not relevant people? :P I should put you there.

[05:28:19.0000] <jgraham>
odinho: Well you have someone from GFX and a random docxs QA. CCing yourself would have improved things :p

[05:28:49.0000] <odinho>
Well, GFX dev does lots of docxs stuff :P

[05:29:28.0000] <Ms2ger>
docxs? Is that something to do with Microsoft Word's XML format?

[05:30:09.0000] <odinho>
Ms2ger: Document parsing, HTML, XML, Javascript, DOM blabla. We have t-shirts! :D

[05:30:14.0000] <zcorpan>
yes. Presto is built on top of Word.

[05:30:27.0000] <odinho>
zcorpan: Shhhh! NDA'd info!111

[05:30:35.0000] <zcorpan>
oops. strike the above.

[05:39:18.0000] <jgraham>
Quick! Out with the official cover up!

[05:39:29.0000] <jgraham>
It stands for "Documents XML and Scripting"

[05:39:37.0000] <jgraham>
But with one extra comma

[05:45:59.0000] <AryehGregor>
Ms2ger, why does Mozilla only run Mozilla/Opera tests from the HTML test suite, instead of everything?

[05:46:09.0000] <AryehGregor>
(at least, all submitted/approved)

[05:46:12.0000] <AryehGregor>
Oh, not even all Opera tests.

[05:48:01.0000] <AryehGregor>
Actually, why don't we run all webapps tests why we're at it?

[05:48:17.0000] <AryehGregor>
Even if the tests are broken, nothing wrong with checking if we regress on broken tests.

[05:48:27.0000] <AryehGregor>
(and yes, this was meant to be in #whatwg, not #developers)

[05:50:15.0000] <odinho>
^_^ I agree. I've imported all of webapps/ and webappsec/ tests to Opera's system at least.

[05:50:34.0000] <zcorpan>
but we don't have html/ right?

[05:50:47.0000] <AryehGregor>
Some of html/ is useful.

[05:50:50.0000] <jgraham>
We have bits and pieces of /html/

[05:50:54.0000] <AryehGregor>
My base64 tests, if nothing else.

[05:51:16.0000] <jgraham>
But really we need one more piece of infrastructure so that we can mimic the w3c-test.org server

[05:51:33.0000] <jgraham>
Rather than having a whole general mish mash of tests, like today

[05:52:06.0000] <jgraham>
(the WGMM appraoch will also require local patches to some tests, which is the main reason it's bad)

[05:52:17.0000] <AryehGregor>
I'm not sure we actually support the w3c-test.org server.

[05:52:32.0000] <jgraham>
We obviosuly don't load tests off that server

[05:53:01.0000] <jgraham>
But we want our local server to look like that server in terms of paths, subdomains, etc.

[05:59:43.0000] <AryehGregor>
Can you still run the tests on some random localhost that way?

[06:01:44.0000] <zcorpan>
we generally don't run tests on random localhosts

[06:02:27.0000] <jgraham>
Unlike Mozilla we have a central server taht is used to store tests

[06:02:50.0000] <jgraham>
I'm not sure this is the best possible setup, but it would be a huge undertaking to redesign it

[06:06:19.0000] <jgraham>
Of course being able to run tests on localhost is a big win

[06:06:33.0000] <jgraham>
But I generally just set up my localhost to be like the main server

[06:10:02.0000] <odinho>
pacman -S nginx; cd /var/www/htdocs; git clone the-tests; opera http://localhost/

[06:10:05.0000] <odinho>
Not that hard ;-)

[06:12:59.0000] <jgraham>
odinho: As long as you don't depend on the specific subdomains or server config

[06:13:29.0000] <odinho>
Well then any random localhost wouldn't work anyway. I guess.

[06:13:54.0000] <jgraham>
I think the Mozilla setup involves a custom web server

[06:14:11.0000] <jgraham>
So I assume AryehGregor isn't comparing to "a random localhost"

[06:14:51.0000] <AryehGregor>
jgraham, in general, anyone with a checkout of Mozilla source code is supposed to be able to run tests.

[06:15:10.0000] <AryehGregor>
I believe a copy of lighttpd is set up on localhost, and various magic protocols and such are enabled.

[06:15:20.0000] <AryehGregor>
So perhaps we could fake w3c-test.org if we wanted.

[06:15:24.0000] <AryehGregor>
Although AFAIK, so far we don't.

[06:42:59.0000] <darobin>
jgraham, AryehGregor: if you could put together your requirements for just cloning w3c-test.org locally and send them to public-test-infra it would be sweet

[06:43:06.0000] <darobin>
I'm sure there's something that we can do there

[06:43:12.0000] <AryehGregor>
darobin, what requirements?

[06:43:15.0000] <AryehGregor>
And whose?

[06:43:45.0000] <darobin>
AryehGregor: reading the logs I got the impression that you wanted to run all the w3c-test.org tests in one bundle, pulled locally

[06:43:49.0000] <darobin>
maybe I read too fast :)

[06:44:01.0000] <AryehGregor>
Nope, not particularly.

[06:44:51.0000] <darobin>
ok, well that's even easier to make happen :)

[06:45:05.0000] <AryehGregor>
jgraham, why is the name argument to test() optional?  It encourages people to omit it, probably because they don't know it exists.

[06:46:51.0000] <jgraham>
AryehGregor: Because it uses the document title if there is no argument

[06:46:59.0000] <odinho>
For cases where you have one test.

[06:47:07.0000] <AryehGregor>
jgraham, yes, which is almost never what you want.

[06:47:11.0000] <gsnedders>
Bloody hell, Oracle makes useless software.

[06:47:12.0000] <AryehGregor>
Okay, if there's only one test.

[06:47:15.0000] <AryehGregor>
Granted.

[06:47:19.0000] <jgraham>
AryehGregor: It is often what I want :)

[06:47:21.0000] <AryehGregor>
But it should fail if you try to do it with more than one test.

[06:47:24.0000] <AryehGregor>
Really?

[06:47:28.0000] <AryehGregor>
You want them to just be named sequentially?

[06:47:31.0000] <gsnedders>
(Trying to enroll for universities courses. Failing.)

[06:47:35.0000] <jgraham>
Well I am often writing things with one test per file

[06:47:42.0000] <jgraham>
At the moment

[06:48:02.0000] <darobin>
failing would kill a number of existing suites — warning might be better, at least temporarily

[06:48:34.0000] <AryehGregor>
jgraham, that's fine, but not if there's more than one test in the file.

[06:50:23.0000] <jgraham>
AryehGregor: It isn't *that* bad (tests get unique numbers)

[06:50:33.0000] <AryehGregor>
jgraham, it's incomprehensible to human readers.

[06:50:34.0000] <jgraham>
But I guess I wouldn't oppose warning for this

[06:51:04.0000] <Ms2ger>
AryehGregor, because it takes some effort to pull them in and add the expectation JSONs

[06:51:16.0000] <Ms2ger>
Especially before I had this script to do it for me

[06:51:22.0000] <AryehGregor>
Ms2ger, okay, makes sense.

[06:51:57.0000] <Ms2ger>
And I think I already landed the patch that makes w3c-test.org to localhost on the mochitest server

[06:52:36.0000] <Ms2ger>
Also, not lighttpd but something based on xpcshell, I think

[06:53:03.0000] <AryehGregor>
Baidu's tests are actually valid, interestingly, albeit very simple.

[06:53:07.0000] <AryehGregor>
They catch some WebKit bugs.

[06:54:10.0000] <AryehGregor>
Oh, of course.

[06:54:34.0000] <AryehGregor>
WebKit will fail all these isContentEditable checks because it implements editability as a CSS property, and the element is detached, so it doesn't compute style.

[06:54:37.0000] <AryehGregor>
Hah.

[06:55:22.0000] <odinho>
AryehGregor: There is already a warning in the default w3c-test report.

[07:00:21.0000] <darobin>
AryehGregor: irrespective of how it's implemented, should a detached element actually be editable anyway?

[07:02:08.0000] <Stevef_>
gsnedders: Opera makes useless software (for AT users) ;-)

[07:02:25.0000] <Ms2ger>
Objection!

[07:02:29.0000] <Ms2ger>
It's useless to me too :)

[07:03:22.0000] <Stevef_>
Ms2ger: did you mean FORMAL OBJECTION/

[07:03:25.0000] <Stevef_>
?

[07:04:19.0000] <Ms2ger>
I don't do those...

[07:04:20.0000] <Ms2ger>
Often

[07:05:02.0000] <odinho>
I lol'd.

[07:05:07.0000] <Ms2ger>
/me eats cake instead

[07:05:37.0000] <odinho>
Hm, me as well. Screw you guys, I'm going to a party (only problem, it just started raining :/ ).

[07:09:25.0000] <darobin>
Ms2ger: is this the manifest to use for the HTML5 tests? http://w3c-test.org/html/tests/approved/html5_approvedtests.txt

[07:09:43.0000] <darobin>
/me is trying to fix the problem with running those tests you noticed a week or two back

[07:11:06.0000] <Ms2ger>
Dunno

[07:11:33.0000] <darobin>
in either case the DB currently has 188 tests which matches none of those manifests — I reckon it's a classic case of the import being out of date with the repo

[07:11:42.0000] <darobin>
/me wishes this architecture were less broken...

[07:12:07.0000] <Ms2ger>
/me would suggest loading the manifest straight out of the repo

[07:12:26.0000] <darobin>
I think there should be no manifest

[07:12:46.0000] <darobin>
the TF should spider the repos and just grab anything that has test metadata

[07:14:38.0000] <darobin>
Ms2ger: yeah, reimporting fixes the 500 — BROKENARCH WONTFIX

[07:14:39.0000] <Ms2ger>
Heh, test metadata

[07:15:32.0000] <darobin>
I don't care if it's just something that says "I'm a test" — that's all I'd need :)

[07:16:05.0000] <darobin>
but anyway, since that works I can move on to break something else

[07:23:06.0000] <AryehGregor>
darobin, editing commands shouldn't do anything to it, no, because it shouldn't have a selection in it.  Per current spec, though, isContentEditable should still return true.

[07:23:42.0000] <AryehGregor>
darobin, what's "test metadata"?

[07:23:47.0000] <AryehGregor>
How do you exclude support files?

[07:24:11.0000] <AryehGregor>
We should have a script that refuses pushes if there's a file that's not found in a manifest, or something like that.

[07:24:50.0000] <darobin>
AryehGregor: there's a bunch of stuff you can put in a test file that says things like who is to blame for this stupid test, what section of the spec it maps to, which assertion it's testing, etc.

[07:25:06.0000] <AryehGregor>
Okay.

[07:25:12.0000] <AryehGregor>
Do all test files have such metadata?

[07:25:17.0000] <darobin>
muahahaha

[07:25:20.0000] <darobin>
well

[07:25:26.0000] <darobin>
in the CSS WG they tend to have decent metadata

[07:25:27.0000] <AryehGregor>
Also, what about if you have stupid things lying around in the checkout like vim swap files or something?

[07:25:32.0000] <darobin>
elsewhere it's much more random

[07:26:14.0000] <darobin>
you grab whoever checked in their swap file and slam their heads repeatedly against hardened ox dung until they stop doing it

[07:27:03.0000] <darobin>
there's a reason I have a travel budgetr

[07:28:25.0000] <darobin>
we could indeed do something with commit hooks that check manifests, but you'd still have to detect which files are test files and which aren't

[07:28:43.0000] <darobin>
which is doable with a few simple conventions though

[07:29:04.0000] <darobin>
it would be a little bit hairy to handle repos that have multiple manifests, e.g. the HTML tests

[07:30:27.0000] <jgraham>
How would you even defer session history to HTML.next? That doesn't make any sense…

[07:33:50.0000] <jgraham>
Also there is no good way to do test metadata. In band, out of band, it all sucks

[07:39:42.0000] <darobin>
jgraham: yeah, but it's pretty useful all the same

[07:41:28.0000] <darobin>
unlike, say, my good friend the Opera Mobile Emulator

[07:41:49.0000] <Ms2ger>
darobin, metadata in html files is feasible, but I'm not sure how you want it to look in JS

[07:42:31.0000] <darobin>
Ms2ger: Peter added support for individual testharness tests to carry their own metadata beyond name

[07:42:44.0000] <darobin>
though I'm not sure how much sense that makes to me, yet

[07:43:02.0000] <darobin>
beyond that, you can have magic comments, a sidecar file, whatever

[07:43:34.0000] <Ms2ger>
Yeah, Peter wants to duplicate all the metadata, though :(

[07:43:46.0000] <darobin>
none of it is nice — but short of putting it in another layer (e.g. a Web UI that just looks at the files and that you can annotate) I'm not sure what would work best

[07:43:56.0000] <darobin>
well, yeah, don't get me started on that...

[07:44:07.0000] <darobin>
I'm not sure that starting off the CSS WG's input was the best move here

[07:44:20.0000] <Ms2ger>
I'm not sure what the use case is for per-test() metadata is, fwiw

[07:44:21.0000] <jgraham>
FWIW just having a way to say "this file is a test" is all we need

[07:44:42.0000] <darobin>
I'd like to know which tests are automated and which aren't

[07:44:56.0000] <jgraham>
Sure and the test type

[07:45:05.0000] <jgraham>
But actually I want "this URL is a test"

[07:45:09.0000] <darobin>
so that you can tell someone "go to this URI and run all the automated tests we have, it'll cost you no time"

[07:45:15.0000] <darobin>
yes!

[07:45:16.0000] <darobin>
FFS

[07:45:17.0000] <jgraham>
Because files aren't tests

[07:45:29.0000] <Ms2ger>
*It'll only cost you a lot of CPU time

[07:45:40.0000] <darobin>
last time I brought that up Peter wrote the idea off immediately

[07:45:56.0000] <darobin>
in the current system, the file name uniquely identifies a test across all the suites

[07:45:58.0000] <darobin>
*yay*

[07:46:27.0000] <Ms2ger>
Yeah, that sucks

[07:46:35.0000] <darobin>
if I had more than two weeks left on this project, I'd rewrite it from the ground up

[07:47:36.0000] <jgraham>
Oh if it assumes that, it's doomed

[07:47:58.0000] <jgraham>
We have a system that tries to make believe that files are testcases

[07:48:20.0000] <jgraham>
It is very bad

[07:49:22.0000] <Ms2ger>
The csswg install of the framework likes to tell me I've got unreviewed tests

[07:49:30.0000] <Ms2ger>
... the index.html

[07:50:25.0000] <darobin>
hahaha

[07:56:31.0000] <Ms2ger>
/me wishes howcome would stop indenting his >'s

[08:16:26.0000] <SimonSapin>
1in is 96px in CSS, but 90px in SVG: http://www.w3.org/TR/SVG/coords.html#Units … but browsers use 96 anyway. (But not non-brower SVG engines.)

[08:35:59.0000] <Ms2ger>
"For example, suppose that the user agent can determine from its environment that "1px" corresponds to "0.2822222mm" (i.e., 90dpi)."

[08:36:17.0000] <Ms2ger>
That doesn't seem to require using 90dpi

[08:39:07.0000] <dglazkov>
good morning, Whatwg!

[08:39:49.0000] <Ms2ger>
Good day

[08:43:49.0000] <smaug____>
dglazkov: what on earth are "Web Components standard spec meetings"?

[08:44:21.0000] <smaug____>
/me thinks he hasn't got all the information

[08:44:31.0000] <smaug____>
nor most of the Mozillians in WebApps wg

[08:44:57.0000] <dglazkov>
I am excited to learn that there are now meetings! Are you guys meeting?

[08:45:14.0000] <dglazkov>
what's the context, btw?

[08:45:48.0000] <jgraham>
/me doesn't even know what smaug____ is talking about so is the most out of the loop :(

[08:45:49.0000] <smaug____>
dglazkov: https://bugzilla.mozilla.org/show_bug.cgi?id=783129#c9

[08:45:55.0000] <dglazkov>
ah. let me read

[08:46:00.0000] <jgraham>
OTOH that means I am the winner!

[08:48:05.0000] <smaug____>
dglazkov: is dbuc not talking about some web apps wg conf calls? nor Google+Mozilla meetings?

[08:48:17.0000] <smaug____>
but something else

[08:48:54.0000] <dglazkov>
ah yes. I met with Daniel a bunch of times now. Also with Blake, and before that with Neil and Jonas. I wouldn't qualify them as "standard spec meetings", rather discussions around Web Components.

[08:49:27.0000] <dglazkov>
 You guys are too mean to Daniel. I think he's being defensive.

[08:49:31.0000] <jgraham>
Now I *know* I am the most out of the loop :p

[08:49:59.0000] <Ms2ger>
Anyway, Hixie is speccing it all now, so we're good

[08:51:41.0000] <smaug____>
dglazkov: well, seems like he doesn't quite know how standardization works

[08:52:06.0000] <smaug____>
dglazkov: also, I don't want to use Mozilla's bugzilla to fix spec issues

[08:52:16.0000] <smaug____>
W3C has a bugzilla for that

[08:52:18.0000] <dglazkov>
smaug____: yes and yes.

[08:52:34.0000] <dglazkov>
smaug____: let me respond in bug and take discussion over to w3c bugzilla

[08:53:59.0000] <smaug____>
dglazkov: anyhow, I hope you can pick up my comments and fix those issues in the spec :)

[08:55:07.0000] <dglazkov>
smaug____: yes sir!

[08:55:11.0000] <dglazkov>
/me saluts

[08:55:33.0000] <dglazkov>
smaug____: heeey, I was wonderin'

[08:55:42.0000] <dglazkov>
smaug____: got some spare cycles to work on that stuff? :)

[08:56:06.0000] <smaug____>
dglazkov: btw, I was wondering if using "prototype" in the dictionary might cause some problems

[08:56:16.0000] <smaug____>
dglazkov: I actually might have some time for this

[08:56:24.0000] <dglazkov>
yaaaay

[08:57:00.0000] <smaug____>
dglazkov: I'm going to be in MV next week... and will figure out there what all I'll do in the near future

[08:57:24.0000] <dglazkov>
smaug____: let's meet! I'll buy you lunch.

[08:57:38.0000] <dglazkov>
well, technically, it'll just be free food at Google :P

[08:57:44.0000] <smaug____>
:p

[09:02:37.0000] <dglazkov>
jgraham: are you also interested in Web Components or did I catch the tail of another thread?

[09:02:51.0000] <jgraham>
dglazkov: Interested, yes

[09:03:03.0000] <jgraham>
Although I don't have as much time to work on it as I would like

[09:03:10.0000] <jgraham>
And the Googleplex is so far away

[09:03:29.0000] <dglazkov>
well, there's the VC of various sorts.

[09:03:49.0000] <dglazkov>
and I don't mean venture capitalist here.

[09:04:59.0000] <jgraham>
Dammit, I thought you were going to offer me a few million $ to build a social media website for web components

[09:05:13.0000] <gsnedders>
jgraham: What? Opera hasn't got a teleportation device yet?

[09:05:26.0000] <gsnedders>
jgraham: Or has Opera done it first and simply you don't have the recieving end at Google?

[09:05:28.0000] <dglazkov>
jgraham: Instagraham

[09:06:01.0000] <smaug____>
gsnedders: must be the latter.

[09:06:18.0000] <smaug____>
/me needs to try Opera's teleportation feature

[09:06:51.0000] <gsnedders>
This was the real reason for Opera Unite's name. Tying everyone together by bringing them together.

[09:07:49.0000] <jgraham>
First the word thing and now this. It's leak-city on #whatwg today

[09:18:15.0000] <dglazkov>
I am kind of worried that the discussions on bugzilla are getting no visibility for the rest of WG, but I would hate to spam public-webapps@ with all of them.

[09:20:00.0000] <dglazkov>
should we have another mailing list? I try to summarize activity with my progress update mails, but these are kind of post-factum.

[09:22:15.0000] <jgraham>
I don't mind having a web components mailing list

[09:22:22.0000] <jgraham>
Or having everything on webapps

[09:22:39.0000] <jgraham>
Having it all in bugzilla substantially reduces visibility though

[09:26:43.0000] <smaug____>
dglazkov: .createElement isn't supported but innerHTML is ?

[09:26:55.0000] <smaug____>
that is odd

[09:28:21.0000] <dglazkov>
smaug____: yeah, it is. It's very easy to support with custom tags, but right now, the spec is using the "is" attribute syntax, and there's no easy way to accomplish this.

[09:29:44.0000] <smaug____>
hmm, spec is talking about x-

[09:30:32.0000] <dglazkov>
smaug____: yes, but it's still the attribute value.

[09:30:50.0000] <smaug____>
hmm, right

[09:30:59.0000] <smaug____>
then .register is somewhat odd

[09:35:28.0000] <darobin>
dglazkov: yes, please, I don't care if it's all on webapps or a separate list but it would be better than bugzilla!

[09:36:30.0000] <smaug____>
dglazkov: www-dom is low traffic mailing list

[09:36:35.0000] <dglazkov>
darobin, jgraham: sent mail

[09:36:49.0000] <darobin>
dglazkov: rockin'

[09:37:21.0000] <jgraham>
dglazkov: Great, thanks\

[09:41:33.0000] <dglazkov>
smaug____: yes, the machinery would look less odd if we used custom tags. I am also thinking of this machinery as a step toward just implementing all HTML elements as custom DOM elements. With that in mind, "is" attribute is less appealing.

[09:42:05.0000] <smaug____>
implementing all HTML elements as custom DOM elements?

[09:42:10.0000] <smaug____>
I doubt that will happen

[09:42:14.0000] <smaug____>
there are security issues

[09:42:23.0000] <smaug____>
of course internally browsers can do it

[09:42:32.0000] <smaug____>
but web pages... no

[09:42:45.0000] <jgraham>
Has firefox got a keyboard shortcut for the error console? Unity seems to have decided that I'm not allowed to see the ment

[09:42:49.0000] <jgraham>
*menu

[09:42:59.0000] <dglazkov>
smaug____: well, right. this is a UA implementation detail

[09:43:06.0000] <smaug____>
ctrl+shift+j is error console

[09:43:28.0000] <smaug____>
dglazkov: long ago bryner started to implement all form controls using XBL

[09:43:59.0000] <dglazkov>
bryner... I haven't heard that name in a long time

[09:44:00.0000] <smaug____>
(he never finalized that )

[09:44:41.0000] <smaug____>
/me has no idea what bryner does nowadays... thought he was still @Google but maybe not

[09:47:16.0000] <smaug____>
Gecko has also support for XTF, so that privileged JS can implement new elements. It has been only for new namespaces, and it was used mainly in the XForms project

[09:47:37.0000] <smaug____>
hmm, is there something in XTF that should be brought to web components...

[09:52:04.0000] <smaug____>
dglazkov: FYI, http://mxr.mozilla.org/mozilla-central/source/content/xtf/public/nsIXTFElement.idl?force=1

[09:52:45.0000] <smaug____>
I guess we don't need most of that any time soon

[09:52:55.0000] <smaug____>
except default handling for events

[10:02:09.0000] <Ms2ger>
Ugh, XTF

[10:02:20.0000] <smaug____>
nothing wrong with XTF

[10:03:00.0000] <smaug____>
it is just a very low level way for addons to implement new elements in JS or C++

[10:03:33.0000] <Ms2ger>
You like perl, I'm not sure I trust your judgment :)

[10:58:27.0000] <dglazkov>
XTF is dangerously close to WTF, but I am happy to take a look.

[10:58:48.0000] <dglazkov>
oh, would mrbkap know a lot about this?

[11:23:46.0000] <smaug____>
dglazkov: about XTF? no

[11:24:49.0000] <smaug____>
dglazkov: note, I'm not suggesting to have anything like XTF, but the API may give hints what features are possibly needed

[12:17:42.0000] <Yuhong>
A 90 day trial of Win8 RTM is available here: http://msdn.microsoft.com/en-us/evalcenter/jj554510.aspx

[12:44:54.0000] <jgraham>
Someone should tell dbaron that over-picky review hasn't been a problem in the HTML WG

[12:45:33.0000] <jgraham>
Getting review on the other hand...

[12:45:42.0000] <Yuhong>
IMO it would have helped a lot if DOM access could be restricted between some document.write calls.

[12:46:02.0000] <Ms2ger>
IMO it would have helped if we never had document.write at all

[12:46:07.0000] <Yuhong>
such as document.write("&"); document.write("amp;")

[12:47:17.0000] <Yuhong>
But the DOM was invented after document.write and I don't think it would have been feasible.

[12:47:45.0000] <Yuhong>
I would have suggested this as a compromise.

[12:48:31.0000] <Ms2ger>
Rather unfortunate that you didn't

[12:48:56.0000] <jgraham>
Wait, what?

[12:49:13.0000] <Yuhong>
Of course, it is too late to do it now.

[12:49:34.0000] <jgraham>
You want the behaviour of DOM methods to depend on the current character in the input stream?

[12:49:44.0000] <jgraham>
And you think that would make things better?

[12:50:08.0000] <Yuhong>
The idea is to not allow access to the inconsistent DOM during certain parser states.

[12:50:36.0000] <Yuhong>
Of course, by the time WHATWG was created, it was far too late to do this.

[12:51:03.0000] <jgraham>
Out of all the problems I have had with document write -- and really I have spent months of my life on document.write problems -- that has never been one

[12:54:15.0000] <dfltr>
Sort of a random question: http://www.whatwg.org/specs/web-apps/current-work/multipage/selectors.html#selector-enabled states that inputs with type="hidden" should be omitted from :enabled, but currently no browsers support this in their qSA implementations. Is this an in-progress feature or a known issue?

[12:54:35.0000] <Yuhong>
Of course, the big problem is back in 1997, security was not as important.

[12:55:01.0000] <Yuhong>
And HTML parsing was not well-defined.

[14:49:06.0000] <tantek>
oh hey dlftr - funny seeing you here :)

[14:49:49.0000] <tantek>
do you have an example page illustrating what you mean re: input type="hidden" and :enabled?

[14:53:12.0000] <dfltr>
Oh hey, it's a tantek! One sec, my example is in the Prototype.js test suite. I'll whip up a public test for it.

[14:58:55.0000] <dfltr>
Test here: http://jsfiddle.net/duHdp/

[14:59:25.0000] <dfltr>
Expected result is that it will log both the enabled text field and the hidden input to the browser's console.


2012-08-17
[01:15:52.0000] <odinho>
Lachy: 21:54 < dfltr> Sort of a random question: http://www.whatwg.org/specs/web-apps/current-work/multipage/selectors.html#selector-enabled states that inputs with type="hidden" should be omitted from  :enabled, but currently no browsers support this in their qSA implementations. Is this an in-progress feature or a known issue?

[01:17:49.0000] <Lachy>
odinho, I mailed whatwg about that issue 2 months ago. Hixie hasn't addressed it yet.

[01:20:08.0000] <odinho>
Lachy: Oookay :D

[01:44:16.0000] <jgraham>
zcorpan: Did you say you had a tool for minimising SVG?

[01:44:34.0000] <zcorpan>
http://simon.html5.org/tools/js/svg-optimizer/

[01:44:50.0000] <jgraham>
Thanks

[01:48:25.0000] <zcorpan>
it doesn't perform some obvious optimization like removing useless namespace declarations, metadata, etc, but that's usually simple to do manually

[01:49:38.0000] <jgraham>
Yeah, it would be nice if it removed inkscape-induced cruft

[01:53:15.0000] <heycam>
jgraham, you can try SVG Scour, which I think had removing inkscape cruft in mind

[01:53:30.0000] <heycam>
http://codedread.com/scour/

[01:54:37.0000] <jgraham>
heycam: Thanks

[04:02:50.0000] <jgraham>
I would like to propose the onlick content attribute

[04:03:13.0000] <jgraham>
Because I seem to be unable to type "click"

[04:05:29.0000] <odinho>
jgraham: propose it on the list

[04:06:11.0000] <jgraham>
Alternatvely I want a device with a humidity sensor

[04:15:08.0000] <krijn>
*fingers crossed*

[04:17:56.0000] <krijnh>
\o/

[04:22:20.0000] <zcorpan>
krijnh: hmm?

[04:23:37.0000] <krijn>
Almost up!

[04:23:52.0000] <zcorpan>
oh

[04:24:02.0000] <zcorpan>
nice

[04:24:25.0000] <krijnh>
http://twitter.com/krijnhoetmer/status/236415363259183104

[04:26:27.0000] <zcorpan>
looks like a case from 1995

[04:26:40.0000] <Ms2ger>
Nice wall

[04:27:04.0000] <Ms2ger>
/me furiously refreshes

[04:27:07.0000] <Ms2ger>
\o/

[04:27:16.0000] <krijn>
Hey, you're working on some bullshit HTML standard from last century, I'm working on a crappy desktop server!

[04:27:59.0000] <krijn>
Stop ignoring the fact XHTML will take over some day!

[04:29:06.0000] <Ms2ger>
/me ignores krijn instead

[04:29:12.0000] <krijnh>
:)

[04:29:14.0000] <krijnh>
Me too!

[04:29:17.0000] <krijn>
Ohnoes!

[04:29:47.0000] <krijnh>
http://krijnhoetmer.nl/irc-logs/ up again?

[04:30:39.0000] <Ms2ger>
It is

[04:31:01.0000] <Ms2ger>
/me waves at the peanut gallery

[04:31:39.0000] <krijnh>
Is irc.w3.org still relevant?

[04:32:16.0000] <krijnh>
Is this topic already old?

[04:32:22.0000] <krijnh>
Should I stfu again?

[04:32:58.0000] <odinho>
All that smart stuff I wrote in the down time, noone will ever see it...

[04:33:32.0000] <zcorpan>
krijnh: you mean #html-wg?

[04:33:32.0000] <odinho>
Unless you take donations of logs? :P

[04:33:32.0000] <odinho>
Although I guess i should s/smart/stupid/ and not donate any logs so people see the reality :P

[04:33:53.0000] <krijnh>
zcorpan: yeah

[04:34:17.0000] <krijnh>
odinho: I could fill up the gaps, yes

[04:37:31.0000] <krijn>
Stevef: there, you can power up my PageRank again via Twitter ;)

[04:46:43.0000] <jgraham>
krijn: You realise that you could buy a Raspberry Pi for like 25 USD and it would be better than that thing, right? :p

[04:47:15.0000] <krijn>
No

[04:49:43.0000] <jgraham>
It would be smaller and use less electricity. That's better along some axis. I admit that it wouldn't allow you to use floppy disks.

[04:50:58.0000] <krijn>
Nor my awesome mIRC logger

[04:52:18.0000] <Ms2ger>
Didn't rniwa implement testharness.js support for webkit?

[04:53:28.0000] <jgraham>
I thought he did something at least

[05:01:45.0000] <AryehGregor>
Oh, did he?

[05:01:47.0000] <AryehGregor>
Awesome!

[05:03:09.0000] <krijn>
lol Stevef

[05:03:49.0000] <Stevef>
krijn: i like to be obliging

[05:08:54.0000] <krijn>
Some background, for those caring: we had a little second hand clothes shop, an office and a house (where my mother, brother and sister lived), but they had to throw away all of that (high server costs! ;) and start over again somewhere else. Server now is in a new (much smaller) clothes shop, but office and family is gone there. Result: a much slower internet connection in the new place (less usa

[05:08:54.0000] <krijn>
ge). If anyone thinks it's too slow, I'm open for donations :]

[05:20:43.0000] <Ms2ger>
/me likes http://testsuite.org/

[05:50:27.0000] <AryehGregor>
krijn, what are the requirements for a host?

[06:05:08.0000] <AryehGregor>
Did you say this thing actually runs in mIRC?

[06:06:20.0000] <Ms2ger>
He appears to have said that

[06:06:46.0000] <AryehGregor>
:/

[06:06:48.0000] <AryehGregor>
No wonder.

[06:08:34.0000] <svl>
krijn is just very, very good at paving cowpaths

[06:08:43.0000] <jgraham>
Actually logging IRC doesn't seem to be that hard. krijn's main value proposition is the little yellow markers people can use to stoke up flamewars

[06:08:48.0000] <svl>
or at least at placing the occasional cobblestone on them

[06:13:50.0000] <Stevef>
jgraham: http://krijnhoetmer.nl/irc-logs/whatwg/20120817#l-81 thats BS!

[06:49:17.0000] <AryehGregor>
jgraham, we currently detect unreliable tests by hand, file bugs on them by hand, add comments to the bugs by hand every time a known-flaky test fails using a special web interface, and then if a test starts failing far too much we disable it indefinitely by editing our test manifests by hand.  And when too many tests fail on a platform, we just completely silence reporting of tests for that platform until someone goes through all the failure

[06:49:17.0000] <AryehGregor>
s and alters all the test manifests to skip the platform.  By hand.

[06:49:47.0000] <AryehGregor>
Oh, and our Android test devices like to randomly die during tests, so that on any given test run a few Android runs will usually fail with no explanation.

[06:50:16.0000] <jgraham>
I see

[06:51:41.0000] <jgraham>
When we add a testit is first run 200 times to check that it produces consistent results. If it doesn't it is marked as unstable and the results are ignored for the purposes of regression detection.

[06:53:17.0000] <jgraham>
Then we can also mark failures in stable tests as non reproducable and query to see which tests are producing too many non reproducable fails

[08:20:45.0000] <dglazkov>
good morning, Whatwg!

[08:39:23.0000] <jarek>
Hi

[08:40:17.0000] <jarek>
what's the official stance on presentational attributes in SVG? Are they considered to be good or bad practice now?

[08:41:14.0000] <jarek>
presentational attributes in HTML were deprecated long time ago, will this also happen with SVG for the sake of consistency?

[08:41:44.0000] <zcorpan>
SVG is an image format, it's inherently presentational

[08:42:18.0000] <jarek>
zcorpan: but it shares a lot of CSS rules with HTML

[08:42:44.0000] <zcorpan>
that doesn't make it any less an image format

[08:44:14.0000] <zcorpan>
(gotta go)

[08:44:59.0000] <shepazu>
jarek: they are still supported, and will be for the foreseeable future. There's nothing wrong with presentational attributes, but if you don't like them, don't use them

[08:46:05.0000] <jarek>
I'm not really convinced that having two ways for doing the same thing is good for the standard

[08:46:28.0000] <jarek>
presentational attributes made sense back when XSLT and SMIL were alive

[08:47:14.0000] <shepazu>
jarek: you think that deprecating all content using presetanational attributes is better for the standard?

[08:47:46.0000] <jarek>
shepazu: in the longer run, yes

[08:48:42.0000] <jarek>
shepazu: there are many SVG documents that are mixing both types (e.g. files coded by hand and then tweaked in Inkscape)

[08:49:24.0000] <shepazu>
jarek: this is a pretty philosophical point, and I'm not convinced that it's a problem in practice, nor that the simplistic "style vs. content" argument is relevant to SVG

[08:56:48.0000] <jarek>
is this theoretically possible that HTML5+CSS4will eventually support all the features of SVG?

[08:57:04.0000] <jarek>
gradients, transforms and filters are already there

[08:58:59.0000] <jarek>
the biggest missing feature is <path> element

[08:59:01.0000] <shepazu>
jarek: it's not theoretical… HTML5 already supports all the features of SVG… it's called SVG

[09:00:55.0000] <jarek>
shepazu: all HTML5 does is support for inline SVG element, you still have to work with awkward SVG DOM and use SVG namespaces

[09:01:21.0000] <shepazu>
well, SVG2 will solve some of that

[09:01:45.0000] <jarek>
will it be still XML-based?

[09:02:03.0000] <shepazu>
anyway, HTML5 is feature-frozen, so it would be some future HTML spec, and I don't think it's likely

[09:02:11.0000] <shepazu>
it's markup-based

[09:02:43.0000] <shepazu>
later, I have a meeting now

[09:03:49.0000] <smaug____>
shepazu: luckily this channel is about HTML spec which isn't frozen ;)

[09:05:11.0000] <jgraham>
What is this "frozen" of which you speak?

[09:12:31.0000] <jgraham>
smaug____: Your history tests scare me. I look at them, go "oh, surely everyone's interoperable on that" and then get 3 different behaviours in three browsers

[09:17:59.0000] <Ms2ger>
jgraham, could have got 5

[09:31:39.0000] <tantek>
Lachy, odinho re: that input hidden and :enabled issue - was that logged in bugzilla? can we add this testcase/example to it? Test here: http://jsfiddle.net/duHdp/ (from dfltr)

[09:32:47.0000] <jgraham>
Hmm, so if I understand the spec correctly, the behaviour of history.go(-1); history.go(1) depends on whether the previous page is in the fast back cache

[09:33:41.0000] <jgraham>
Um, not quite

[09:33:52.0000] <jgraham>
But something like that

[09:34:07.0000] <jgraham>
Oh, no that is an example

[09:34:49.0000] <jgraham>
Or, maybe I am wrong

[09:35:00.0000] <Ms2ger>
Maybe?

[09:35:13.0000] <jgraham>
Well I am clearly wrong about some things

[09:35:18.0000] <jgraham>
I think this is one of them

[09:35:57.0000] <jgraham>
For some reason I thought that the navigate algorithm cleared out any other history traversal tasks

[09:36:38.0000] <jgraham>
Hmm, maybe it does

[09:36:58.0000] <jgraham>
Depends what calls "update the session history with the new page"

[09:38:15.0000] <jgraham>
Ah, but this is "entry update"

[09:38:30.0000] <jgraham>
Should probably think somewhere other than IRC

[10:47:23.0000] <Hixie>
sicking: do you have a link to the e-mail where you asked for popstate to not fire during load? I thought the spec used to prevent that, and the Mozilla proposal was to switch to firing it always because it was considered really bad to stop links from working while the page was loading some huge image, or something.

[10:48:38.0000] <sicking>
Hixie: i don't have a link no. Define "during load"

[10:48:50.0000] <sicking>
Hixie: we requested multiple change

[10:48:52.0000] <sicking>
s

[10:49:13.0000] <sicking>
Hixie: one was to remove the behavior of "always fire a popstate event when firing a load event"

[10:49:53.0000] <sicking>
Hixie: another was to "allow popstate to fire while the page is loading, I.e. before the load event has fired, when a history traversal happens"

[10:52:42.0000] <sicking>
Hixie: the blog post explains it pretty well, no?

[11:02:14.0000] <Hixie>
sicking: i thought your e-mail just now was requesting that we not fire it while page was loading?

[11:02:19.0000] <Hixie>
sicking: maybe i misread your e-mail

[11:02:42.0000] <sicking>
Hixie: i might have been unclear

[11:03:12.0000] <Hixie>
"it's unfortunate if the spec still calls for popstate to be fired during pageload"

[11:03:34.0000] <Hixie>
i guess that can eb read both ways

[11:03:52.0000] <Hixie>
anyway as far as i know the spec exactly matches the requests you (mozilla) made

[11:12:07.0000] <sicking>
Hixie: yeah, i think i read it the other way

[11:12:15.0000] <sicking>
Hixie: lemme recheck the thread and clarify

[11:14:22.0000] <sicking>
Hixie: i think he's saying that the spec calls for popstate to automatically fire when the initial "load" event fires for a page load. So no state transitions happening other than loading the page

[11:15:22.0000] <sicking>
Hixie: in fact, i'm quite certain that is what he says given the provided examples

[11:16:05.0000] <sicking>
i'll check if his spec quotes are accurate, but if they are the spec doesn't follow the mozilla proposal

[11:16:32.0000] <Hixie>
i'm not aware of 'popstate' being mentioned anywhere near the 'load' event

[11:16:38.0000] <Hixie>
they're in different chapters

[11:17:21.0000] <Hixie>
the only place in the spec that fires popstate is the "traverse the history" algorithm, and then only if /state changed/ is true

[11:18:00.0000] <Hixie>
that's true when the page is first navigated to, but that's _long_ before 'load' fires

[11:19:16.0000] <Hixie>
(in fact in most UAs I'd expect that to happen before you have any chance of hooking an event handler for it)

[11:20:10.0000] <Hixie>
(it is guaranteed to be before any script execution, though i guess not before the <body onpopstate> is parsed, so it could theoretically be detected)

[11:21:31.0000] <sicking>
Hixie: define "when the page is first navigated to"

[11:22:02.0000] <sicking>
Hixie: the mozilla proposal was that popstate only fires when transitioning sessionhistory entries by the current Document doesn't change

[11:22:36.0000] <Hixie>
well you definitely have to fire it if you go from doc A at state 1 to doc B and back to doc A at state 2

[11:22:49.0000] <Hixie>
i guess we could not fire it when you're going to the document for the first time

[11:23:10.0000] <sicking>
how could you go back to doc A at state 2?

[11:23:24.0000] <Hixie>
(first navigated = when the Document has no session history entry that it has ever been traversed to)

[11:23:31.0000] <sicking>
if you left doc A at state 1 to doc B, and then go back, wouldn't you end back at state 1 in doc A?

[11:23:46.0000] <Hixie>
not if you go forward or back in the session history by more than one step at a time

[11:24:22.0000] <sicking>
ah, yes

[11:25:07.0000] <sicking>
so if you have three entries in SH: <A, 1> <A, 2> <B, 1>. And then go from first to third, no popstate fires. but if you then go from third to second, popstate does need to fire

[11:25:29.0000] <Hixie>
right

[11:25:46.0000] <Hixie>
currently, if you click on a link to <C, 1>, it also fires, as soon as the page is shown

[11:25:51.0000] <Hixie>
we can change that though

[11:25:58.0000] <sicking>
but if you have <A, 1> <A, 2> and the user is at the second state and clicks a link to document B then no popstate should fire at any time

[11:26:03.0000] <Hixie>
(there's no risk of compat issues since you can barely ever detect it anyway)

[11:26:22.0000] <sicking>
yeah, i think we should change that

[11:26:34.0000] <Hixie>
currently the spec treats that as if you are going from <B, null> to <B, 1>, which is why it fires the event, fwiw

[11:27:17.0000] <sicking>
it's unclear what the compat risk is since i don't know how much of the page can be parsed at that time. But gecko already does this, so i'm not too worried about compat risk

[11:27:25.0000] <sicking>
especially for Gecko since we wouldn't change :-)

[11:27:38.0000] <Hixie>
and the other browsers ahven't updated to the new model anyway, right?

[11:27:47.0000] <sicking>
i don't think Webkit does what the spec currently or Gecko does though

[11:28:01.0000] <sicking>
i thought webkit had implemented the gecko model a long time ago, but apparently they have bugs

[11:28:09.0000] <sicking>
this stuff really really needs a test suite

[11:28:20.0000] <sicking>
i'm quite worried that IE gets it totally wrong

[11:28:29.0000] <Hixie>
filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=18605

[11:30:21.0000] <sicking>
thanks

[12:00:03.0000] <nvartolomei>
.

[12:37:57.0000] <Yuhong>
Just posted this: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-August/036933.html

[13:52:25.0000] <jgraham>
sicking: Hmm we have tests for the history state stuff. Did we not release them?

[13:52:47.0000] <jgraham>
Oh we did

[13:52:49.0000] <jgraham>
http://w3c-test.org/html/tests/submission/Opera/historyinterface/

[13:53:20.0000] <sicking>
jgraham: They apparently missed this case though, since I believe Gecko passes them

[13:53:51.0000] <jgraham>
sicking: Not the gecko I have here at least

[13:54:15.0000] <jgraham>
They might have missed this case of course, we don't claim to write perfect tests :)

[13:54:19.0000] <sicking>
hmm.. yeah, you're right. I seem to recall being told we pass, but i'm clearly wrong

[13:54:36.0000] <jgraham>
Patches welcome of course

[14:33:00.0000] <zewt>
(opera history api seemed pretty broken when I was testing recently; clicking <a href=#foo> didn't fire onpopstate)

[14:36:22.0000] <jgraham>
zewt: Write a test and we will fix it

[14:41:30.0000] <zewt>
i really wish there was a web app I could just write, run and submit tests from

[14:44:14.0000] <jgraham>
Yes, several people have suggested that

[14:44:38.0000] <jgraham>
But really, even a live DOM viewer page that demonstrates the problem and can be turned into a real test would be fine

[14:45:53.0000] <zewt>
well, it's pretty straightforward, eg. https://zewt.org/~glenn/test-same-hash.html clicking the links does nothing

[14:46:35.0000] <zewt>
fortunately I can polyfill it pretty easily

[14:53:15.0000] <zewt>
hmm, is it intentional that when postMessage(stuff, [transfer map]) throws DataCloneError, sometimes the objects are neutered and sometimes they're not (depending on when the exception is thrown)?

[15:48:15.0000] <rniwa>
how do I write a nullable method using WebIDL?

[15:49:33.0000] <zewt>
nullable method?

[15:49:37.0000] <rniwa>
yeah

[15:49:43.0000] <rniwa>
that may or may not exist.

[15:59:03.0000] <TabAtkins_>
Don't think you can.

[16:00:35.0000] <zewt>
doesn't really mesh with prototype chains

[16:01:23.0000] <TabAtkins_>
Yeah, you'd have to override the method on the instance to be undefined.


2012-08-18
[19:06:55.0000] <gavinc>
cross window javascript would be right nice right now

[19:07:59.0000] <gavinc>
maybe I can make postMessage work

[19:54:27.0000] <zewt>
firefox taking a new top seat of the month for bad ui: fullscreening dims the window every single time

[19:55:31.0000] <zewt>
smells like contrived security issues that don't actually actually exist being used as an excuse to annoy every user of (sites that use) the api

[19:56:11.0000] <zewt>
... switching youtube back to flash

[21:44:26.0000] <gsnedders>
So, those following progress of html5lib will be happy to hear I've just regressed almost every test.

[22:08:32.0000] <gsnedders>
And now we're basically working on Py3!

[22:08:52.0000] <ruby_on_tails>
hello

[22:46:41.0000] <zewt>
bleh, only thing i seriously dislike about dom events is how capturing event listeners aren't run before non-capturing event listeners in the AT_TARGET phase; easily its biggest, ugliest wart

[04:06:53.0000] <jgraham>
https://github.com/mozilla/mozilla-central

[04:07:28.0000] <jgraham>
Anyone know if that's a one-way sync or there is some solution for pushing there?

[04:10:12.0000] <Ms2ger>
It's one-way

[08:13:45.0000] <zewt>
wish people would stop rolling the rand()%2?"URL":"URI" dice and just call them what they are: URLs

[08:22:56.0000] <divya>
zewt++++

[08:25:11.0000] <zewt>
particularly silly when people talk about the "URIs" returned by "createObjectURL"

[09:01:40.0000] <divya>
ahahahah

[09:01:48.0000] <divya>
URIs must die

[12:02:16.0000] <tantek>
indeed. URLs++ :)

[12:07:38.0000] <zewt>
(i don't particularly care about which definition is used--just the silly idea that we have two different things that people actually differentiate between)

[12:16:11.0000] <tantek>
zewt TBH sometimes "URL" in the name of an API is purely legacy for naming reasons, and it may have been expanded to return URIs without bothering to change the name.

[12:16:54.0000] <tantek>
usually this is easy enough to determine by asking the question is there anyway the API can return something like an "isbn:" URI

[12:18:20.0000] <tantek>
also WP asserts that "about:" is a "URI" scheme (more than a "URL" scheme) http://en.wikipedia.org/wiki/About_URI_scheme

[12:18:50.0000] <tantek>
so if an API can return an "about:…" value, then it's returning a URI rather than a URL (unless we want to rewrite that Wikipedia article)

[12:19:52.0000] <tantek>
for ISBN: I see how it makes sense to call it a URI (*identifier*) rather than a URL ("locator/location" etc.)

[12:20:48.0000] <tantek>
for about: I'm on the fence - it's always "felt" like a URL to me (it goes somewhere predictable and does something) rather than a URI, but I don't really have the energy/time to fight that fight on Wikipedia.

[12:21:07.0000] <tantek>
or perhaps someone who has a better understanding of why "about:" is considered a URI could explain why that is, rather than just a URL.

[12:22:04.0000] <tantek>
but your overall statement I have to agree with, in typical conversation it makes sense to just refer to URLs.

[12:27:46.0000] <tantek>
ok, by this WP defn, I think about: could be considered a URL scheme: http://en.wikipedia.org/wiki/Uniform_Resource_Locator#URLs_as_locators

[12:28:01.0000] <tantek>
"provides a means of locating the resource by describing its primary access mechanism (e.g., its network location)"

[12:28:14.0000] <tantek>
primary access mechanism = the browser

[12:28:37.0000] <tantek>
for about:

[12:29:36.0000] <zewt>
i don't see any point to even drawing the distinction

[12:29:42.0000] <tantek>
and that quote is apparently even from http://tools.ietf.org/html/rfc3986

[12:29:48.0000] <tantek>
1.1.3. URI, URL, and URN

[12:29:56.0000] <tantek>
which is a better citation that WP

[12:30:12.0000] <tantek>
ergo, I think we can assert that about: URIs are actually just URLs.

[12:31:00.0000] <tantek>
I'm not sure it ever made sense to come up with URIs that were *not* URLs. e.g. how useful is isbn: ?

[12:32:24.0000] <zewt>
useful for linking, in the intent sense (if the user can configure which site he wants to view book references on); doesn't make sense for generic fetching (xhr)

[12:33:24.0000] <zewt>
same with mailto, irc, anything else intent-y

[12:39:32.0000] <zewt>
though I suppose in principle they could, if they defined a protocol, eg. if isbn: was defined as returning a JSON block with the title and author--the user could plug in whatever data service he wants and sites requesting isbn:1234 would get data from that service

[12:40:26.0000] <zewt>
then doing an xhr fetch on isbn:12345 would be no different than http://amazon.com/get-isbn-info/12345 (not to say that would actually be useful, just that there doesn't *have* to be any difference)

[13:06:32.0000] <tantek>
I guess I don't see a point to linking to a scheme (like ISBN: ) until it actually does something (like mailto: and irc: already do something)

[13:06:57.0000] <tantek>
even others one might presume would be popular, like "tel:" have had very little uptake in practice

[13:07:35.0000] <tantek>
at least that's been our experience with microformats like hCard, people will markup a class="tel" but not bother to figure out how to make a "tel:" hyperlink work - too much hassle.

[13:08:34.0000] <tantek>
e.g. does anyone know if *any* of the (supposed) smart phones out there have a browser that when you click on a "tel:" hyperlink actually launches the phone/dialer application to dial the phone number?

[14:03:46.0000] <adlwalrus>
is the foreget param of location.reload standardized?


2012-08-19
[23:21:31.0000] <ruby_on_tails>
an arc starts from the rightmost point, how can i change that to the topmost point ?

[08:08:18.0000] <gsnedders>
jgraham: Have a working copy of html5lib that's gone through 2to3 and 3to2, needing slight work after the latter. 5% quicker at parsing the spec, likely down to no implicit str/unicode conversions.

[08:08:27.0000] <gsnedders>
(Also, am in Lkpg)

[08:29:36.0000] <Ms2ger>
gsnedders, \o/

[09:03:28.0000] <gsnedders>
So, the main challenge with 3to2: how do I have a string literal which is always the "str" type (i.e., a byte string on Py2 and a unicode string on Py3).

[09:10:35.0000] <Ms2ger>
Preprocess your python in python

[09:33:15.0000] <jgraham>
gsnedders: Why do you need that?

[09:33:45.0000] <jgraham>
If you do then you would do something like:

[09:34:05.0000] <jgraham>
def foo(x):

[09:34:19.0000] <jgraham>
    if python2:

[09:34:31.0000] <jgraham>
        return str(x)

[09:34:35.0000] <jgraham>
    else:

[09:34:44.0000] <jgraham>
        return unicode(x)

[09:34:57.0000] <jgraham>
Or whatever the right function names are

[09:46:59.0000] <zewt>
jgraham: may as well do "foo = str if python2 else unicode" in that case, heh

[10:07:22.0000] <Ms2ger>
"While Opera has a history of lying to sites for compatibility reasons, most other browsers do not."

[10:07:23.0000] <Ms2ger>
Orly

[10:22:25.0000] <jgraham>
Ms2ger: Hahaha

[10:22:33.0000] <jgraham>
Where's that from?

[10:23:03.0000] <Ms2ger>
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0486.html

[10:23:38.0000] <jgraham>
Man, Tab should know better than that

[12:58:42.0000] <gsnedders>
jgraham: Ah, but 2to3 will convert str(x) to unicode(x).

[12:58:51.0000] <gsnedders>
jgraham: Or rather 3to2.

[12:59:21.0000] <gsnedders>
jgraham: So you end up with return unicode(x) on both branches.

[13:11:13.0000] <jarek>
Hi

[13:12:02.0000] <jarek>
if you specify HSLA values to CSSOM, should it be converted and stored as RGBA?

[13:12:23.0000] <jarek>
e.g.:

[13:12:25.0000] <jarek>
element.style.color = 'hsla(100, 40%, 50%, 0.5)'

[13:12:48.0000] <jarek>
element.style.color

[13:13:05.0000] <jarek>
> "rgba(110, 179, 76, 0.498039)"

[13:13:15.0000] <jarek>
this is how it works on both Firefox and Chrome

[13:13:29.0000] <jarek>
this is not what I would have expected

[13:19:59.0000] <gsnedders>
Both always return <color> values as rgba. There's a fair bit of sense in this, as all the various CSS syntax forms are stored as a normalized colour value internally, and in Firefox/Chrome it isn't stored what the input form was.

[13:24:42.0000] <jarek>
uhm... but this rather confusing to anyone using this API

[13:26:09.0000] <jarek>
e.g. if you are implementing HSL color picker then the information about hue that user has picked is lost

[13:27:05.0000] <gsnedders>
jarek: It isn't lost, you can get from rgba to hsla.

[13:27:27.0000] <jarek>
gsnedders: it is lost if both saturation and value were 0

[13:28:13.0000] <jgraham>
gsnedders: You haven't really explained why you need something that is always a str

[13:29:34.0000] <gsnedders>
jgraham: types.ModuleType's first argument is a str in Py2 and a str in Py3.

[13:47:46.0000] <jgraham>
gsnedders: if hasattr(types, "StringTypes"): getattr(types, "StringTypes")[0]; else: str

[13:48:03.0000] <jgraham>
Presumably 3to2 isn't clever enough to convert that

[13:51:04.0000] <gsnedders>
jgraham: Yeah, I was guessing I'd have to do something like that. Which sucks.

[13:51:30.0000] <jgraham>
Only a little bit

[13:52:16.0000] <gsnedders>
(The only other issue is an outright bug in 3to2)

[13:52:39.0000] <gsnedders>
(It deletes a line in a try block. It then doesn't add "pass". Syntax error results.)

[13:52:58.0000] <jgraham>
http://web.archive.org/web/20010621171122/http://www.mozillazine.org/designpatterns/

[13:52:58.0000] <gsnedders>
Still suspect there are other issues around elsewhere  in the code.

[13:53:31.0000] <zewt>
gsnedders: if you just want to get the str function without it being converted, i'd hope __builtins__.str wouldn't be touched

[13:54:35.0000] <jgraham>
That kind of depends hwo 3to2 works, realy

[13:54:38.0000] <jgraham>
*really

[13:54:51.0000] <gsnedders>
zewt: On the other hand, that makes it dependant on default encoding in Py2.

[13:55:11.0000] <gsnedders>
(Whereas I really just want ISO-8859-1)

[13:59:57.0000] <jim>
what is a whatwg?


2012-08-20
[20:05:54.0000] <heycam>
TabAtkins_, what happened to author-ident in css3-values? (what grammar symbol should I use instead?)

[20:20:54.0000] <Yuhong>
http://www.w3.org/wiki/Evolution

[20:20:58.0000] <Yuhong>
I wonder what happened

[20:21:13.0000] <Yuhong>
http://www.w3.org/2001/tag/2011/12/evolution/

[01:30:10.0000] <miChou>
Good morning/evening! :)

[01:32:16.0000] <jgraham>
(in India it is the afternoon)

[01:33:07.0000] <miChou>
does morning..evening does the trick then? :D

[01:33:45.0000] <odinho>
miChou: Yeah, good morning :-)

[01:34:02.0000] <jgraham>
In 'frisco it is the middle of the night :)

[01:34:15.0000] <miChou>
1:34 to be more precise

[01:34:22.0000] <jgraham>
(I hear that people really don't like it if you call it 'frisco :)

[01:36:21.0000] <miChou>
TabAtkins_: ping?

[01:37:04.0000] <odinho>
jgraham: So that's why you do it? To spite'em?

[01:52:24.0000] <jgraham>
odinho: That and http://www.youtube.com/watch?v=VJ19ahNyM3I :)

[02:09:34.0000] <odinho>
jgraham: Sssss!

[02:17:56.0000] <jgraham>
Hmm, I am missing something about what happens if you do history.go(-1); history.go(-1)

[02:19:03.0000] <jgraham>
(alternative theory: the spec is missing something)

[02:19:24.0000] <jgraham>
(but at this juncture I will guess it is more likely me)

[02:22:50.0000] <gsnedders>
Do we file a bug on jgraham if he's wrong?

[03:40:54.0000] <zcorpan>
wonder if there's anything in http://necolas.github.com/normalize.css/ that can be changed in browsers/the spec

[06:28:11.0000] <odinho>
Hrmf. I can't find chromium nightly builds.

[06:28:26.0000] <odinho>
They're just gone from the old new place they were moved to.

[07:53:20.0000] <jgraham>
OK, I think I have current browser behaviour worked out

[07:53:34.0000] <jgraham>
In Opera, first navigation wins

[07:53:52.0000] <jgraham>
history.go(-1); history.go(-2) will take you back 1

[07:54:06.0000] <jgraham>
In gecko/webkit last navigation wins so you will go back 2

[07:54:11.0000] <jgraham>
*but*

[07:54:31.0000] <gsnedders>
There's always a but, isn't there?

[07:55:00.0000] <jgraham>
If you try to navigate to some undefined point in history last, gecko will ignore it, but webkit will still cancel the previous navigations

[07:55:33.0000] <jgraham>
So history.go(-2) history.go(3) with no forward history will go back 2 in gecko and do nothing in WebKit

[07:56:25.0000] <jgraham>
smaug____: ^ does that sound right?

[07:56:49.0000] <jgraham>
If the spec specifies this then I am skipping over the relevant part when I read it

[07:58:03.0000] <smaug____>
jgraham: sounds right

[07:58:17.0000] <smaug____>
(I mean the Gecko part)

[08:00:24.0000] <smaug____>
(though, I wonder if Gecko's shistory is sync in some cases... need to check)

[08:05:21.0000] <jgraham>
Hmm, and IE does something else again

[08:06:09.0000] <jgraham>
Maybe doesn't ignore anything

[08:07:33.0000] <smaug____>
fun

[08:07:42.0000] <jgraham>
So 21 years after the first web browser was released, we still don't have any operability at all on the fundamental navigation mechanism of the web platform

[08:08:07.0000] <jgraham>
Even though it is probably the simplest possible design

[08:09:35.0000] <gsnedders>
Did WorldWideWeb have back/forwards?

[08:11:26.0000] <smaug____>
Did NS2 have .history

[08:11:38.0000] <smaug____>
or was is it added to NS3

[08:12:38.0000] <gsnedders>
Opera 2 seems to have back/forwards buttons, at least.

[08:15:25.0000] <jgraham>
Well The string "back" appears in the binary. http://www.w3.org/History/1994/WWW/Journals/CACM/screensnap2_24c.gif shows a "navigate" menu

[08:15:27.0000] <smaug____>
"WorldWideWeb's navigation panel contained Next and Previous buttons that would automatically navigate to the next or previous link on the last page visited"

[08:15:50.0000] <jgraham>
Ah yeah

[08:16:34.0000] <jgraham>
Anyway, so we have had quite a while to get this stuff right :)

[08:24:54.0000] <Hixie>
jgraham: fwiw the behaviour of the back button and history.back() in the spec is intended to be a careful choice based on tests and thought, it's not supposed to be incompatible with the web

[08:25:05.0000] <Hixie>
jgraham: however, it is indeed an area with low interop

[08:25:16.0000] <Hixie>
jgraham: so if there is content that isn't compatible, that'd be good to know

[08:25:49.0000] <jgraham>
Hixie: I have no idea about *content*. At the moment I am trying ot figure out what browsers do and what the spec says :)

[08:26:43.0000] <jgraham>
Hixie: Can you give me a high level overview of what the intent of the spec is?

[08:27:05.0000] <jgraham>
Because this stuff is not very easy to follow

[08:27:29.0000] <jgraham>
Unless you know what the expected outcome is

[08:30:28.0000] <Hixie>
i can in a few minutes, can't pay attention right now

[08:30:52.0000] <jgraham>
(afaict, IE has some strange behaviour where if you do something like .go(-1) .go(-1) .go(2) .go(-1) it will ignore the .go(2) because that would take you back to where you first started and you will end up .go()ing -3)

[08:30:56.0000] <jgraham>
Hixie: No problem

[08:31:19.0000] <jgraham>
(but I am hoping that my test is broken because that would be crazy)

[08:31:45.0000] <Hixie>
iirc it's async, and only the last takes effect, but i can give you a more correct answer in a bit

[08:32:40.0000] <jgraham>
I'm pretty sure it's async

[08:32:52.0000] <jgraham>
I haven't yet worked out why only the last would take effect

[08:32:58.0000] <jgraham>
If that is indeed what happens

[08:34:05.0000] <Hixie>
sorry, only the first, assuming you cross a document boundary after the first

[08:34:16.0000] <Hixie>
(still not fully paying attention)

[08:38:43.0000] <Hixie>
ok let's see

[08:39:16.0000] <Hixie>
so anything that happens happens after the script has finished executing, because go() and back() et al do all their work in a queued task

[08:39:48.0000] <Hixie>
they have their own special task source, the history traversal task source

[08:40:11.0000] <Hixie>
part of the pushState() and document.open() methods empties that queue

[08:40:33.0000] <Hixie>
as does "update the session history with the new page"

[08:40:54.0000] <Hixie>
and navigating to a frag id

[08:41:07.0000] <Hixie>
but it doesn't seem it gets emptied by traversal

[08:41:27.0000] <jgraham>
Right, because this is entry update

[08:41:50.0000] <jgraham>
So "update the session history" specifically doesn't empty the queues

[08:42:13.0000] <Ms2ger>
Good morning, Whatwg

[08:42:19.0000] <Hixie>
er yeah, sorry, not empty

[08:42:32.0000] <Hixie>
cleans up a bit :-)

[08:43:39.0000] <Hixie>
assuming the first go(-1) crosses a doc boundary, then all the subsequent ones get ignored, per spec

[08:43:51.0000] <jgraham>
Hmm, I lost something somewhere

[08:44:04.0000] <Ms2ger>
Your car keys?

[08:44:16.0000] <Hixie>
though maybe they would technically still be in the queue when you go back to the doc, heh

[08:44:20.0000] <jgraham>
Isn't traversal the case where the algorithm is initiated for /entry update/?

[08:44:49.0000] <Hixie>
"traverse the history" happens for a number of things

[08:45:01.0000] <Hixie>
go(), pushState(), navigation, etc

[08:45:17.0000] <Hixie>
maybe not pushState()

[08:45:29.0000] <jgraham>
I am specifically wondering about .go() in this case

[08:45:48.0000] <Hixie>
go() definitely invokes it, it's the last step of go()'s algorithm

[08:46:57.0000] <Hixie>
looks like we should be emptying this queue somewhere

[08:47:03.0000] <Ms2ger>
krijn, http://krijnhoetmer.nl/irc-logs/ doesn't seem to update, though the pages ere there

[08:47:04.0000] <Hixie>
that we're not yet doing so

[08:47:27.0000] <Ms2ger>
*are

[08:47:30.0000] <krijn>
Hmpf

[08:48:14.0000] <krijn>
Ms2ger: updated

[08:48:33.0000] <Ms2ger>
That was quick :)

[08:48:41.0000] <krijn>
My cronj...Windows Task Schedule thingy...wasn't running

[08:48:50.0000] <jgraham>
Hixie: OK, so the intent of the spec is to match Opera; i.e. first wins?

[08:49:09.0000] <Hixie>
jgraham: dunno if it matches opera, but first is supposed to win as far as i can tell

[08:50:26.0000] <Hixie>
jgraham: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=18626

[08:51:25.0000] <jgraham>
Hixie: OK, thank you. That is clearer

[08:51:51.0000] <jgraham>
and gives me something to aim for until averyone else decides that they don't agree with this model ;)

[08:52:11.0000] <Hixie>
jgraham: does it match mozilla?

[08:53:27.0000] <smaug____>
jgraham: what? the first go() wins?

[08:53:34.0000] <jgraham>
Hixie: No one matches

[08:53:46.0000] <jgraham>
smaug____: That is apparently the intent of the spec

[08:54:14.0000] <Hixie>
either the step that cleans the task source in the navigation algorithm should be moved to the traverse algorithm, or a step should be placed in the "by a delta" algorithm should have it...

[08:54:22.0000] <Hixie>
jgraham: how do they differ?

[08:54:40.0000] <Hixie>
this is one of those areas where i'm pretty sure i was trying to match either gecko or webkit, probably gecko

[08:55:10.0000] <jgraham>
Hixie: In Gecko last wins, unless it would navigate outside the session history in which case you work backward through the list until there is a valid one

[08:55:31.0000] <jgraham>
so .go(-1) .go(2) with no forward history would be like .go(-1)

[08:55:42.0000] <Hixie>
http://hixie.ch/tests/adhoc/dom/level0/history/ is where i put my tests, though it looks like i didn't save many

[08:56:04.0000] <Hixie>
ah so gecko tests the validity sync, then queues a task, interesting

[08:56:06.0000] <jgraham>
In WebKit last wins always and if it doesn't do anything there is no navigation

[08:56:28.0000] <Hixie>
so webkit essentially clears the task source each time

[08:56:30.0000] <smaug____>
what in the spec says go(-1) should win?

[08:56:39.0000] <jgraham>
In Opera first wins

[08:57:02.0000] <jgraham>
In i.e. all navigations are taken into account so .go(-2) .go(-1) takes yopu back 3

[08:57:35.0000] <jgraham>
But, if my tests are not broken (I think they might be) anything that would lead to no overall navigation is ignored

[08:57:59.0000] <jgraham>
so .go(-2) .go(2) .go(-1) is like .go(-3) not like .go(-1)

[08:58:40.0000] <Hixie>
what about go -2 -2 -2 -2 when you only have 2?

[08:58:42.0000] <Hixie>
does it crash?

[08:59:02.0000] <jgraham>
IE?

[08:59:05.0000] <Hixie>
y

[08:59:36.0000] <Ms2ger>
Does it print random numbers? :)

[09:01:09.0000] <Hixie>
afk brb

[09:01:23.0000] <jgraham>
Just ends up on the first page in history afaict

[09:06:06.0000] <jgraham>
Hixie: I don't know who is supposed to pass your tests, but gecko ends up in the wrong history position, webkit is in an infinite reload loop and Opera fails

[09:06:37.0000] <jgraham>
So if the spec is based on those tests, it doesn't also follwo browsers ;)

[09:12:45.0000] <dglazkov>
good morning, Whatwg!

[09:17:48.0000] <Hixie>
jgraham: maybe it was a combination of the best parts :-)

[09:18:13.0000] <Hixie>
jgraham: anyway, IE's behaviour seems obviously bad (why compare against something you're not going to execute against)

[09:19:14.0000] <Hixie>
jgraham: are you testing with multiple traversals from multiple frames?

[09:19:34.0000] <Hixie>
jgraham: which wins if you have e.g. a subframe go back then a parent go back, all in one task?

[09:19:53.0000] <Hixie>
jgraham: seems to me the "first wins" model is the sanest and easiest to reason about

[09:42:06.0000] <hendry>
hsivonen: hi, do you know how I can set location.search up without making the page reload? https://github.com/kaihendry/Greptweet/issues/20#issuecomment-7875290

[09:43:12.0000] <jgraham>
Hixie: I have only tested top level browsing contexts without children so far

[09:45:55.0000] <miChou>
hi TabAtkins_, you 'around?

[09:49:00.0000] <TabAtkins_>
heycam|away: We killed it pending resolution of some issues around case-normalizing.  At minimum, we're going to make author-defined idents do ascii-case-folding, to match CSS-defined identifier, but we may do unicode-case-folding as well, if we can define an acceptable form that's friendly to atomic string comparison.

[09:49:13.0000] <TabAtkins_>
heycam|away: That's a long way of saying "just use <ident>".

[09:49:41.0000] <TabAtkins_>
miChou: pong

[09:50:33.0000] <TabAtkins_>
Ms2ger: Beyond UA trickery and some quirks mode stuff that *everyone* does, what are examples of other browsers lying to sites?

[09:53:04.0000] <miChou>
TabAtkins_: got a question regarding <br>-s and fragmentation. If I do something like <br style="display: block; width: 1px; height: 1px; break-after: column (or region, or page)"> should it break the column(/region/page), or not? (that is, beside the line breaking that implicitly occurs)

[09:53:23.0000] <miChou>
I sent an email to www-style a week or so ago but did not get a definitive answer :)

[09:54:38.0000] <TabAtkins_>
miChou: Hm, I am not the right person to ask about fragmentation, but let me dig around and see if I can answer this.

[10:08:56.0000] <miChou>
TabAtkins_: thanks a bunch!

[10:12:57.0000] <TabAtkins_>
miChou: Okay, yeah, it should create a break.

[10:21:43.0000] <miChou>
TabAtkins_: ok, good to know. I'll go file some browser bugs :>

[10:25:35.0000] <Hixie>
what's the canonical url for html parsing tests that i should give someone who is writing an html parser?

[10:27:02.0000] <Ms2ger>
html5lib on code.g.c

[10:27:17.0000] <Hixie>
http://code.google.com/p/html5lib/source/browse/#hg%2Ftestdata%2Ftokenizer and http://code.google.com/p/html5lib/source/browse/#hg%2Ftestdata%2Ftree-construction ?

[10:27:28.0000] <Hixie>
is there documentation for the test format?

[10:27:59.0000] <Ms2ger>
... what is this thing you speak of?

[10:28:11.0000] <Hixie>
http://wiki.whatwg.org/wiki/Parser_tests ?

[10:28:37.0000] <Ms2ger>
Oh good

[11:01:00.0000] <jgraham>
TabAtkins: Excluding the most common ways that browsers lie to sites in "ways browsers lie to sites" is just bizzare

[11:01:42.0000] <jgraham>
But even if you do exclude those, Chrome has shipped DOM APIs for features that it didn't actually have

[11:01:59.0000] <TabAtkins>
jgraham: The point was in reference to individual browsers lying, not everyone lying in the same way, which is much less troublesome.

[11:02:25.0000] <jgraham>
But everyone doesn't lie in the same way in their UA string, for example

[11:03:46.0000] <TabAtkins>
Sure, but who cares about UA strings?  It's irrelevant to the philosophical question of "will a new feature detection mechanism work?".

[11:04:11.0000] <TabAtkins>
We got rightly complained at for shipping APIs before the feature was ready, and we're a bit more careful about that now.

[11:04:23.0000] <TabAtkins>
The examples I know of were just sloppy coding, not deliberate lies.

[11:04:46.0000] <jgraham>
Since UA strings are an existing example of a feature detection mechanism, and one in which browsers are still forced to lie, it does seem somewhat relevant

[11:05:52.0000] <jgraham>
Not sure how you managed to ship a whole dom implementation of <details> with no UI through sloppy coding, but my point is not to dwell on the missteps of others

[11:05:53.0000] <TabAtkins>
You could argue that, but I don't think it's significant enough.  It's far removed from actual *feature* testing, so it's no wonder that it gets polluted.

[11:07:20.0000] <jgraham>
We so far we have tried UA strings and hasFeature and feature detection, and they have all been gamed and are all abused by authors

[11:09:06.0000] <TabAtkins>
Yes, because UA strings are *very* far removed from the features we're trying to detect, so they corrupt very easily.  hasFeature is still somewhat removed from the actual feature (level of removal varies on how granular the strings are defined) as whether you return a boolean for a string has no technical connection to the implementation of the feature.

[11:09:21.0000] <TabAtkins>
hasFeature is, I think, *less* corrupted than UA strings, but still too much to be usable.

[11:09:33.0000] <TabAtkins>
(Insofar as they were usable in the first place.)

[11:10:35.0000] <TabAtkins>
supports(), on the other hand, is tightly coupled to the feature, probably as tightly coupled as we can get without actual testing.  The easiest implementation is to just hand it to your CSS parser and see if it's recognized, and what you parse it tightly attached to what you implement and are willing to expose to the world.

[11:10:48.0000] <TabAtkins>
(Again, very occasional missteps in this, but they're quite rare.)

[11:11:22.0000] <TabAtkins>
Plus, the granularity is perfect, because you can test the *exact* syntax you're planning to use.

[11:12:09.0000] <TabAtkins>
This suggests that supports() will be less corrupted than hasFeature() was.  There's still a possibility that "less" is still "too much", but we'll see.

[11:12:17.0000] <TabAtkins>
If this fails, then feature detection in the browser is basically impossible.

[11:12:43.0000] <jgraham>
People won't test the exact thing they will use

[11:13:15.0000] <jgraham>
They will test some thing that is a good proxy for what they want to use in some particular contempary browser

[11:13:29.0000] <jgraham>
This happens all the time with jaascript feature detection

[11:13:38.0000] <TabAtkins>
Not for all cases, no - that would be way too verbose.  But you can take some representative line from you code and use it exactly.

[11:14:34.0000] <jgraham>
Anyway, I don't particularly care about @supports

[11:14:56.0000] <jgraham>
I don't expect it to work well but there is no way I will convince you of that

[11:15:32.0000] <jgraham>
It is nevertheless distressing that you are going around making crazy statements about browsers not lying to make sites work

[11:16:04.0000] <TabAtkins>
I'm sorry that you're ignoring my clarification about that statement. I assumed it was obvious in context, but it may not have been clear.

[11:16:48.0000] <jgraham>
Which clarification? The fact that you were ignoring multiple ways that browsers lie?

[11:16:59.0000] <TabAtkins>
(Assuming you read the context at all. The line by itself, as Ms2ger quoted, is incorrect.)

[11:17:11.0000] <jgraham>
I read the context

[11:17:40.0000] <TabAtkins>
My line starting from "The point was in reference...".  Don't be purposely dense.

[11:18:53.0000] <Ms2ger>
Now you're just being a dick

[11:18:58.0000] <jgraham>
I'm not being. I don't see how even basic stuff like UA strings is "everyone lying in the same way"

[11:19:17.0000] <TabAtkins>
Ms2ger: ffs

[11:20:17.0000] <TabAtkins>
jgraham: I can go further into my reasoning, but I think I explained well enough above, and it's irrelevant anyway - you're less optimistic about trying this kind of thing again, and that's okay.

[11:20:33.0000] <jgraham>
Chrome pretends to be Gecko, Safari and Mozilla. Opera claims to be an older version of Opera. Firefox claims to be Mozilla. etc.

[11:20:35.0000] <TabAtkins>
If you were trying to block the feature, I'd be more concerned about convincing you, but if it's just a personal opinion, you're allowed to hold it. ^_^

[12:00:16.0000] <Hixie>
TabAtkins: btw re @supports and co, i like that it is designed with the hasFeature() lessons in mind. i hope it works, if it does we might be able to reuse this design in the future.

[12:04:52.0000] <zcorpan>
i expect @supports will be used to test what codec to use in webrtc

[12:05:36.0000] <Ms2ger>
if (!CSS.supports("MP3")) { alert("Wrong browser!"); }

[12:05:40.0000] <Ms2ger>
Something like that?

[12:06:13.0000] <TabAtkins>
More like "if( CSS.supports('-moz-foo') { /* use a format that mozilla supports */ }".

[12:07:06.0000] <zcorpan>
right, except not -moz-, just a standard property that mozilla happens to support and iPhone default browser doesn't, or whatever

[12:07:17.0000] <Ms2ger>
Oh, looks like we support iframe sandbox now

[12:08:44.0000] <Ms2ger>
if (CSS.supports("document.all"))

[12:08:56.0000] <TabAtkins>
That'll be false everywhere. ^_^

[12:09:06.0000] <zcorpan>
(the only application of -o-object-fit i've seen in the wild is browser-sniffing for opera of the version where that was added, for an entirely different purpose than the property itself)

[12:25:28.0000] <TabAtkins>
Hixie: Someone internally is asking for window.devicePixelRatio to be standardized, for the purpose of sizing <canvas> properly.  Is this necessary if we expose the HD stuff?

[12:26:51.0000] <Hixie>
no

[12:26:56.0000] <Hixie>
it's exposed as part of the HD stuff

[12:27:25.0000] <Hixie>
http://www.whatwg.org/specs/web-apps/current-work/#dom-screen-canvasresolution

[12:28:07.0000] <TabAtkins>
Excellent, thanks.

[12:28:44.0000] <dglazkov>
smaug____: will tomorrow at 2:00pm work for you?

[12:29:04.0000] <Hixie>
/me goes to add a reference and finds it has 19 editors

[12:29:09.0000] <Hixie>
/me decides to omit that editor list

[12:29:36.0000] <smaug____>
dglazkov: looking at the schedule ...

[12:29:46.0000] <smaug____>
dglazkov: "3pm-4pm: Web components planning "

[12:30:41.0000] <smaug____>
that would be mozilla only stuff...

[12:30:55.0000] <smaug____>
let me ask someone about the previous thing...

[12:32:33.0000] <smaug____>
dglazkov: 2pm should be ok

[12:32:53.0000] <smaug____>
dglazkov: blake should be around too

[12:33:32.0000] <Hixie>
lang=jp isn't valid?

[12:33:38.0000] <smaug____>
dglazkov: ah, saw your email... answering..

[12:33:48.0000] <Hixie>
validator.nu says 'The language subtag "jp" is not a valid ISO language part of a language tag'

[12:37:16.0000] <Hixie>
oh it's ja

[12:50:09.0000] <dglazkov>
smaug____: great, thank you!

[13:48:00.0000] <zcorpan>
TabAtkins: so i want to define hashless and unitless at tree-construction rather than at tokenizer. there's "If the current declaration is grammatically valid, append it to the value of the current rule." so i'd need to rewrite the primitives before that (i guess in "consume a primitive")

[13:49:20.0000] <zcorpan>
and i guess i need to set a flag in declaration mode when seeing the ident token, if it's one of the quirky properties

[13:51:24.0000] <TabAtkins>
zcorpan: Alternately, rewrite it at that "grammatically valid" check-point.

[13:51:51.0000] <TabAtkins>
Check if it's valid.  If not, swap out the tokens for their quirks-mode equivalents, and check again.

[13:52:28.0000] <zcorpan>
yeah but that seems more annoying to spec :-)

[13:55:54.0000] <TabAtkins>
Yeah, setting a flag in declaration mode and converting tokens in declaration-value mode might work.

[13:56:20.0000] <TabAtkins>
I can just put the hooks in directly, if you'd like.

[13:56:20.0000] <TabAtkins>
Also: yay, I can remove the scinot flag and just have it on all the time now!

[13:59:52.0000] <zcorpan>
hooks would be nice

[14:01:19.0000] <TabAtkins>
Just describe what would be convenient for you to use, or alternately, define some hooks on your side so I can just directly reference them.

[14:02:14.0000] <zcorpan>
yeah that works

[14:02:17.0000] <zcorpan>
i wonder when the flags should be unset again

[14:02:40.0000] <zcorpan>
when entering the declaration mode next time?

[14:03:52.0000] <TabAtkins>
Presumably just all the states that exit "declaration parsing".

[14:04:13.0000] <TabAtkins>
That is, the error states in after-declaration-name, and the ending states in declaration-value.

[14:07:38.0000] <zcorpan>
yeah

[14:27:24.0000] <zcorpan>
TabAtkins: i think it would be better to just put the quirks in the parser spec directly

[14:29:48.0000] <zcorpan>
only annoying thing is that it needs to check the names of properties and functions

[14:31:58.0000] <zcorpan>
maybe i can try writing a patch for the parser

[14:51:08.0000] <TabAtkins>
Feel free.  I think it would be workable for the quirks spec to define the set of properties that need quirk handling, and the way in which each is handled.

[14:51:42.0000] <TabAtkins>
But I'm okay with Syntax just handling the whole thing.  My ideal handling of it would just be taking the part I'd want in the quirks spec and putting it in an appendix.

[14:53:41.0000] <zcorpan>
TabAtkins: there's an </h4> missing (top-level mode)

[14:55:12.0000] <TabAtkins>
fixed

[14:55:52.0000] <zcorpan>
v.nu complained about some other errors in the source document also

[15:02:00.0000] <TabAtkins>
Ah, yeah, more markup errors.  Fixed.

[15:32:36.0000] <zcorpan>
TabAtkins: http://simon.html5.org/dump/css3-syntax/ has the original source file (before the fixing of markup errors) and the other file is with quirks added (i didn't add the list of properties though)

[15:36:20.0000] <TabAtkins>
Ah, so I can just diff it?

[15:37:37.0000] <zcorpan>
yeah

[15:42:57.0000] <zcorpan>
now i'm gonna sleep. but i'll read the logs tomorrow so just dump comments here if you have any :-)

[15:43:06.0000] <zcorpan>
nn

[16:09:58.0000] <heycam>
TabAtkins, ok thanks (will use <ident>)


2012-08-21
[17:05:46.0000] <TabAtkins>
zcorpan: Since it looks like the quirks only need to be handled at the "top level" of a property, I was able to put together a much simpler version.  Just made a small addition to the declaration-value mode, and then defined two variants of "consume a primitive" that do the quirky things.

[17:06:32.0000] <TabAtkins>
(Your version was slightly wrong anyway - it was written like there was only a single "quirks-function" flag, when you really need a stack to handle nested functions.)

[17:25:04.0000] <Hixie>
hsivonen: yt?

[17:31:06.0000] <smaug____>
I bit late for hsivonen, I guess

[17:35:25.0000] <Hixie>
yeah, but we can always hope :-)

[20:28:37.0000] <kennyluck>
hi, WHATWG!

[21:07:57.0000] <MikeSmith>
kennyluck: hey man

[21:08:22.0000] <MikeSmith>
kennyluck: we don't have component-watching support in the version of bugzilla we're running

[21:08:40.0000] <MikeSmith>
I think it's a bugzilla 4 feature

[21:09:40.0000] <MikeSmith>
Hixie (or anybody else who's awake): It's possible for a single assertion in the spec to have multiple test cases associated with it, right?

[21:09:49.0000] <kennyluck>
MikeSmith, hmm… ok. I won't be the person pushing for it.

[21:10:20.0000] <MikeSmith>
kennyluck: I'd love to have it too but I don't think we are going to be migrating to v4 any time soon

[21:13:53.0000] <MikeSmith>
about the test-case question, I'm working on a how-to that attempts to explain how to determine what to test in a spec

[21:53:43.0000] <Hixie>
MikeSmith: yeah, of course

[21:54:27.0000] <Hixie>
MikeSmith: e.g. "if the user agent receives a value between 25 and 30, it must show blue" would have at least a dozen tests

[21:54:38.0000] <MikeSmith>
Hixie: yeah sorry I was thinking out loud

[21:55:14.0000] <Hixie>
(-1, 0, 1, 24..31, an arbitrary number above 31, 2**31-1, 2**32, 2**63, not a number...)

[21:55:25.0000] <MikeSmith>
yeah

[21:55:57.0000] <MikeSmith>
I'm using "On setting, if the new value is one of “none”, “copy”, “link”, or “move”, then the attribute’s current value must be set to the new value" for dropEffect as an example

[21:56:43.0000] <Hixie>
that one has many test assertions in one since it applies to many modes, iirc

[21:58:05.0000] <MikeSmith>
ok

[22:00:26.0000] <Hixie>
honestly for most assertions one can come up with a near infinite number of tests

[22:00:40.0000] <Hixie>
the key is to only come up with as many as is required to keep the engineers busy :-)

[22:14:21.0000] <MikeSmith_>
Hixie: :-)

[23:57:07.0000] <jgraham>
MikeSmith: In HTML lots of the musts are "must run the following steps" followed by a multistep algorithm that invokes several other multistep algorithms

[23:57:28.0000] <jgraham>
In such cases it doesn't even make sense to say that you are testing the top-level "must:

[23:57:57.0000] <jgraham>
You are typically trying to test that a particular set of steps in the algorithm are correctly implemented

[23:58:01.0000] <MikeSmith>
jgraham: yeah, understood

[23:58:03.0000] <MikeSmith>
about those

[23:58:33.0000] <MikeSmith>
plh and I working on a W3C "Testing how-to"

[23:59:07.0000] <MikeSmith>
current source is at https://github.com/w3c/testing-how-to

[23:59:20.0000] <MikeSmith>
if you care to take a look and have any comments

[23:59:40.0000] <MikeSmith>
I'm going to be working on the rest of it in the next few hours

[00:00:36.0000] <jgraham>
OK

[00:04:19.0000] <jgraham>
MikeSmith: I think Hixie tries to write so that "foo is bar" statements are always just factual i.e. they fall out of some other part of the spec

[00:04:27.0000] <jgraham>
But others are not so careful

[00:04:32.0000] <MikeSmith>
yeah I know

[00:05:41.0000] <MikeSmith>
when I see that pattern in the HTML spec, I can be confident it's just stating a fact for which the actual requirements are stated elsewhere

[00:06:02.0000] <MikeSmith>
but no such confidence for most other specs

[00:06:47.0000] <jgraham>
Also, it's basically impossible to write tests that just test one thing. I mean as soon as you depend on the parser, or the DOM, or whatever that's making the assumption that many other things work

[00:07:24.0000] <jgraham>
The trick is to be clear about what is acceptable to assume and what is not

[00:08:49.0000] <jgraham>
You can probably assume that the parser works, as long as you are not doing anything funky. But you might have to be careful around less interoperable bits of the spec or bits more closely related to the subject of your test

[00:09:05.0000] <MikeSmith>
OK

[00:10:09.0000] <jgraham>
s/reading the entire spec/reading the spec/

[00:10:41.0000] <jgraham>
There is *some* modularity, even in something like HTML ;)

[00:10:59.0000] <MikeSmith>
k :-)

[00:12:43.0000] <jgraham>
The testharness.js example with firstElementChild is horrible

[00:13:35.0000] <jgraham>
assert_true(!!something) is ugly because it's deliberately undermining the test harness

[00:14:24.0000] <jgraham>
The right tests to use there would be assert_idl_attribute

[00:14:52.0000] <jgraham>
But people don't like that because the interoperability on where the attributes go on the prototype chain is so poor

[00:16:56.0000] <Ms2ger>
I don't use assert_idl_attribute because I always forget it exists :)

[00:17:07.0000] <MikeSmith>
jgraham: I will pass that on to plh

[00:17:10.0000] <MikeSmith>
he wrote that part

[00:17:45.0000] <jgraham>
Also the link to the navigation timing tests is not optimal

[00:17:57.0000] <Ms2ger>
/me blames these tests being manual before

[00:17:57.0000] <MikeSmith>
why?

[00:18:05.0000] <jgraham>
Because they add a layer of indirection on top of the testing framework

[00:18:19.0000] <jgraham>
For some reason

[00:18:29.0000] <jgraham>
Hardly the most obvious example to lean from

[00:18:33.0000] <jgraham>
*learn

[00:19:18.0000] <MikeSmith>
ah OK

[00:20:26.0000] <jgraham>
I don't know what is the *best* example to use

[00:24:56.0000] <Ms2ger>
My tests, duh :)

[00:25:29.0000] <jgraham>
Something like Opera's classList tests or something

[00:26:03.0000] <jgraham>
Ms2ger: You submitted so many it was hard to find a nice self-contained example with > 1 test per page and not too much extraneous stuff

[00:26:17.0000] <jgraham>
Well I don't mean extraneous

[00:26:51.0000] <jgraham>
I mean "extra functions and stuff that are not just direct use of the test harness"

[00:27:14.0000] <Ms2ger>
And testing something you don't have to read four specs to understand? :)

[00:29:04.0000] <jgraham>
I wasn't so concerned with whether people would understand the pass condition ;)

[00:29:12.0000] <jgraham>
Maybe something from DOM?

[00:50:51.0000] <Ms2ger>
Hrm

[00:51:32.0000] <Ms2ger>
jgraham, is jl someone you can forward questions to?

[00:51:55.0000] <jgraham>
Ms2ger: Yes, in general. No now in specific (he is on vacation)

[00:52:09.0000] <Ms2ger>
Hm

[00:52:48.0000] <Ms2ger>
Then, do you know why new Event("foo").eventPhase is AT_TARGET in Opera?

[00:53:05.0000] <Ms2ger>
It's NONE in Chrome and Gecko

[00:53:20.0000] <Ms2ger>
And afaict in the spec

[00:53:33.0000] <jgraham>
It could just be a bug

[00:55:01.0000] <Ms2ger>
Also, I guess I shouldn't use assert_idl_attribute for methods

[00:57:00.0000] <Ms2ger>
Oh

[00:57:05.0000] <Ms2ger>
Opera doesn't have Event.NONE?

[00:58:30.0000] <odinho>
Ms2ger: Yeah, seem to remember something like that.

[00:59:11.0000] <odinho>
Ms2ger: sof just fixed `contains` on Node not Element, btw. Thanks for the heads up. :)

[00:59:24.0000] <Ms2ger>
Ah, nice

[01:03:38.0000] <odinho>
Ms2ger: So... Are you writing this test just now?

[01:04:51.0000] <Ms2ger>
Which?

[01:05:03.0000] <Ms2ger>
I'm adding a bit to http://localhost/tests/webapps/DOMCore/tests/submissions/Ms2ger/Event-constructors.html

[01:05:34.0000] <Ms2ger>
(With obvious substitution to get a URL you can access :))

[01:07:38.0000] <Ms2ger>
odinho, so about those IDB tests...

[01:12:12.0000] <Ms2ger>
jgraham, dunno what you were looking at for the example, but maybe http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Event-constructors.html ?

[01:14:05.0000] <gsnedders>
Ms2ger: We simply never added support for Event.NONE, so no.

[01:14:20.0000] <Ms2ger>
gsnedders, do you have a bug?

[01:16:44.0000] <gsnedders>
Ms2ger: odinho claimed not

[01:17:15.0000] <odinho>
odinho was thinking about making it when having a test to add to it :P

[01:18:43.0000] <gsnedders>
odinho: Work quicker!

[01:18:54.0000] <Ms2ger>
http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Event-constants.html

[01:18:59.0000] <odinho>
gsnedders: Imma like multitasking, you might steal that task.

[01:19:30.0000] <odinho>
Ms2ger: What about those?

[01:21:01.0000] <Ms2ger>
odinho, are Microsoft's tests completely redundant?

[01:21:17.0000] <odinho>
Ms2ger: Yeah, -- and they're wrong.

[01:24:50.0000] <Ms2ger>
odinho, can we get rid of them?

[01:25:58.0000] <jgraham>
Microsoft?

[01:29:12.0000] <jgraham>
Ms2ger: Those tests might be OK, although the pattern of having multiple independent asserts in the same test is mildly troubling

[01:29:20.0000] <odinho>
(Some places)

[01:29:20.0000] <odinho>
They get 40% pass on my version of their own tests. While they get 100% on their own.

[01:29:20.0000] <odinho>
Or they're probably just not as strict. I should investigate why they get such a low score. Sshouldnt be like that.

[01:30:04.0000] <jgraham>
I mean it's not bad and I do it too, but it isn't the nicest bit of testharness.js

[01:31:29.0000] <odinho>
Ms2ger: Hmm. Well, it's Alex that's test facilitator for IDB, -- so guess there'll be hurt feelings etc if you just remove them :P

[01:31:41.0000] <odinho>
And I guess they're updating them some more behind the scenes.

[01:35:00.0000] <zcorpan>
TabAtkins: unitless needs to work in rect(10 10 10 10)

[01:44:41.0000] <jgraham>
gsnedders: http://packages.python.org/six/

[01:49:38.0000] <gsnedders>
jgraham: Still not sure it helps me.

[01:49:42.0000] <gsnedders>
jgraham: Have looked before, etc

[03:42:58.0000] <Ms2ger>
zcorpan, it's only the terms defined in html.json that get into html-generated.json... Would be nice to get them pulled out of the spec somehow

[03:44:16.0000] <zcorpan>
yeah

[03:45:18.0000] <zcorpan>
maybe the spec splitter can output a json with all the terms and their urls?

[03:45:35.0000] <zcorpan>
or i guess the splitter doesn't care about terms

[03:46:03.0000] <zcorpan>
but anolis itself knows what the terms are when it generates the spec

[04:06:31.0000] <odinho>
Ms2ger: Heh, did you actually have AT_TARGET in the test before there? Why? Only tested in Opera ( ;-) ).

[04:07:32.0000] <Ms2ger>
odinho, I blame annevk / jl

[04:10:27.0000] <odinho>
lol, I wonder how that happened

[04:10:46.0000] <Ms2ger>
zcorpan, I guess jgraham runs that instance...

[04:11:12.0000] <Ms2ger>
odinho, "hey, let's test the initial values of some stuff"

[04:11:20.0000] <Ms2ger>
odinho, "let's check what Opera returns"

[04:11:24.0000] <Ms2ger>
(I assume)

[04:11:47.0000] <odinho>
Ms2ger: Ah, so you say you didn't write it. That makes it clearer :-)

[04:12:03.0000] <Ms2ger>
Yeah, my name in the URL is a lie

[07:12:12.0000] <zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18631 was filed on whatwg/html but is now moved to htmlwg/canvas. not that i understand the bug really and i'll be happy to not get emails for the spam he generates, but what's our story with bugs filed on the w3c specs?

[07:17:16.0000] <zcorpan>
i guess someone(tm) should keep an eye on the w3c bugs and clone the ones that are relevant

[07:19:23.0000] <zcorpan>
also, MikeSmith, can you ask that user to behave in bugzilla (not spam)

[07:33:18.0000] <Ms2ger>
zcorpan, fwiw, he also filed https://bugzilla.mozilla.org/show_bug.cgi?id=783942

[07:33:44.0000] <zewt>
[Great Idea]

[07:34:57.0000] <zcorpan>
yeah, shows the same behavior

[07:38:12.0000] <zcorpan>
i'll just send him an email

[08:25:58.0000] <hober>
zcorpan: yeah, things shouldn't get moved from whatwg/html to an htmlwg component; they should be cloned.

[08:27:34.0000] <zcorpan>
hober: feel free to move it back and clone it (or say it should be cloned in a comment)

[08:28:20.0000] <zewt>
(cloning bugs is a pretty great way to fragment discussion and confuse everyone)

[08:30:26.0000] <jgraham>
Well yeah, but so is having two specs developing in parallel that are mostly the same but have subtle differences

[08:30:52.0000] <jgraham>
The only thing it's better than (in this case) is *not* doing that

[08:31:07.0000] <zewt>
doing two horrible things is generally considered worse than doing one horrible thing

[08:31:53.0000] <jgraham>
You have a proposal for how to organise the bugs so taht no cloning is needed but the specs aren't coupled in the way they were before?

[08:37:32.0000] <zewt>
you ask that as if cloning bugs is actually a "solution"

[10:17:44.0000] <TabAtkins>
zcorpan: Ah, you're right, I missed that.  I'll add that in.

[10:27:05.0000] <smaug____>
abarth: ping

[10:27:11.0000] <abarth>
smaug____: hi

[10:27:26.0000] <smaug____>
abarth: just curious, how does webkit handle expandos on DOM nodes

[10:28:03.0000] <smaug____>
element.fooproperty = element; for example

[10:28:16.0000] <smaug____>
/me is quite amazed that cycles are so hard for webkit

[10:29:29.0000] <abarth>
I'm not sure I understand your question

[10:29:40.0000] <abarth>
expandos are handled inside the javascript engine

[10:29:44.0000] <abarth>
and are not represented in C++

[10:29:58.0000] <smaug____>
but C++ object doesn't keep the JS wrapper alive?

[10:30:59.0000] <abarth>
not directly

[10:31:16.0000] <abarth>
we use the C++ object graph to inform the JS engine about connections between the wrappers

[10:31:27.0000] <abarth>
the JS engine then decides whether those connections mean that the wrappers should be kept alive

[10:32:19.0000] <smaug____>
ah

[10:32:46.0000] <smaug____>
so there is mini cycle analyzer somewhere

[10:32:49.0000] <smaug____>
kind of

[10:33:03.0000] <smaug____>
cycle or connection analysis ...

[10:33:04.0000] <abarth>
https://docs.google.com/presentation/d/1OFG81taxgjOGU43sv9WHvPZkt5--KnM6gSijWN8NMcU/edit?disco=AAAAAECHbXY#slide=id.g16a516bb_1_53

[10:33:14.0000] <abarth>
see slide 53 and onwards in that presentation

[10:33:33.0000] <abarth>
the JavaScript garbage collector can deal with cycles

[10:33:38.0000] <abarth>
because it uses mark-and-sweep

[10:33:48.0000] <abarth>
however, cycles cause leaks in the C++ heap

[10:33:57.0000] <abarth>
WebKit has a separate heap for C++ objects and for JavaScript objects

[10:34:31.0000] <smaug____>
sure, same with Gecko

[10:34:41.0000] <smaug____>
but Gecko just can deal with cycle in C++ too

[10:34:47.0000] <smaug____>
and C++->JS->C++ cycles

[10:35:10.0000] <smaug____>
and based on the comments, also Opera and IE can deal with C++->JS->C++ cycles easily

[10:35:51.0000] <smaug____>
so I'm rather reluctant to change APIs because of one engine

[10:35:52.0000] <abarth>
sadly, WebKit isn't that smart

[10:35:59.0000] <TabAtkins>
Yet.

[10:36:01.0000] <abarth>
well, then we won't be able to implement the API

[10:36:17.0000] <abarth>
its not possible to do without massive changes to the engine

[10:36:21.0000] <abarth>
or memory leaks

[10:36:34.0000] <smaug____>
TabAtkins: yeah, I assume webkit will have to be changed to handle cycles

[10:36:44.0000] <abarth>
that's not going to happen

[10:36:55.0000] <smaug____>
why not?

[10:36:56.0000] <TabAtkins>
Kentaro is investigating moving DOM to JS.

[10:37:11.0000] <abarth>
smaug____: are you volunteering to do the work?

[10:37:19.0000] <smaug____>
no :)

[10:37:23.0000] <abarth>
smaug____: because it's quite difficult

[10:37:27.0000] <smaug____>
I have enough fun with Gecko's cycle collector

[10:38:01.0000] <abarth>
TabAtkins: kentaro concluded that we shouldn't do it because it would be slower, at least based on current designs

[10:38:44.0000] <abarth>
smaug____: I don't intend to be a stick in the mud, it's just not something that's possible to implement in a feasible amount of time

[10:38:45.0000] <TabAtkins>
I don't believe Kentaro is set on that, and others in the thread are more optimistic about experimenting with this.

[10:39:18.0000] <abarth>
TabAtkins: well, blocking UndoManager on DOM-in-JS basically means UndoManager won't happen anytime soon

[10:39:43.0000] <TabAtkins>
Ah, I didn't know the context of this discussion.

[10:40:36.0000] <smaug____>
abarth: oh, sure, something like CC isn't a trivial task. Has taken ages to get performance to reasonable level in Gecko.

[10:43:34.0000] <smaug____>
but still, limiting Web APIs just because one engine hasn't been updated to have such a core memory management functionality would be odd

[10:44:42.0000] <abarth>
smaug____: You're welcome to have whatever opinion you like on that topic.  The facts on the ground are that we cannot implement the API as specified.  Therefore, if you'd like WebKit to implement the API, the specification needs to change.

[10:46:17.0000] <smaug____>
or someone needs to fix webkit to handle cycles and implement undomanager after that

[10:47:27.0000] <abarth>
smaug____: right, but the schedule for that is basically "not any time soon", so it's the same as not implementing it

[10:47:49.0000] <smaug____>
/me doesn't agree :)

[10:48:07.0000] <abarth>
it's not a matter of opinion

[10:48:13.0000] <abarth>
what part don't you agree with?

[10:48:25.0000] <abarth>
you think someone is going to change WebKit's memory model sometime soon?

[10:48:34.0000] <smaug____>
"it's the same as not implementing it"

[10:48:51.0000] <smaug____>
you can implement UndoManager next year

[10:48:56.0000] <abarth>
it won't happen

[10:49:29.0000] <smaug____>
(there must be some huge pressure inside Google to get UndoManager to Chrome)

[10:50:55.0000] <abarth>
why do you say that?

[10:51:04.0000] <smaug____>
just wondering

[10:51:11.0000] <smaug____>
why you can't implement UndoManager later

[10:51:12.0000] <jamesr>
if you have to implement a cycle collector to implement UndoManager i can't imagine why we would ever do it

[10:51:19.0000] <smaug____>
and try to fix memory management first

[10:51:32.0000] <abarth>
smaug____: later => never

[10:51:41.0000] <jamesr>
if this is the only thing in the web platform that requires it, why would we do something so complicated and slow?

[10:51:48.0000] <abarth>
because it's unlikely we'll ever implement this new memory management model

[10:51:48.0000] <smaug____>
jamesr: I'm pretty sure there will be plenty of web APIs which will cause similar cycle issues

[10:52:06.0000] <abarth>
not that will be implemented in WebKit

[10:53:27.0000] <smaug____>
jamesr: cycle collector doesn't need to be slow

[10:53:38.0000] <jamesr>
but it is

[10:53:47.0000] <smaug____>
in normal cases it isn't

[10:53:51.0000] <smaug____>
when optimized

[10:54:15.0000] <abarth>
smaug____: please feel free to contribute a patch

[10:54:21.0000] <abarth>
smaug____: without code, I don't believe you

[10:54:47.0000] <abarth>
as far as I can tell, it requires at least one extra brach for every Node edge write

[10:54:58.0000] <abarth>
or at least, we haven't figured out a design that can avoid that branch

[10:55:05.0000] <abarth>
maybe one exists

[10:55:40.0000] <abarth>
now, it's possible we can get that speed back by removing an increment operation, but we've optimized out almost all of the increment operations

[10:57:49.0000] <othermaciej>
smaug____, abarth: I'm skeptical of multiple UndoManagers per document anyway

[10:58:05.0000] <smaug____>
Oh, that is different thing

[10:58:12.0000] <othermaciej>
the use case provided (vector graphics editor embedded in a rich text editor) doesn't work the way it's proposed in real apps

[10:58:17.0000] <smaug____>
we certainly need one UndoManager per input field

[10:58:29.0000] <othermaciej>
for example, Keynote lets you edit vector graphics and text in the same document

[10:58:38.0000] <othermaciej>
and it exposes a single undo list per window

[10:58:55.0000] <othermaciej>
in fact, it's the norm for all Mac apps to have a single undo list per window

[10:59:04.0000] <othermaciej>
even if the window holds a compound document, or multiple text fields

[10:59:14.0000] <othermaciej>
I don't know for sure about other platforms

[10:59:31.0000] <othermaciej>
but at least as proposed, the API would result in web apps violating the Mac HI guidelines

[10:59:51.0000] <zewt>
(mac UIs make me want to cut myself)

[10:59:58.0000] <smaug____>
:)

[11:00:15.0000] <othermaciej>
are there any platforms where native apps really do have separate modal undo lists?

[11:00:27.0000] <smaug____>
rniwa: you were testing this

[11:00:42.0000] <smaug____>
and yes, there are such apps

[11:01:21.0000] <othermaciej>
the use cases document that I looked at didn't seem to list real-world examples (but I may have overlooked it)

[11:01:54.0000] <othermaciej>
in any case, even if apps like that are the norm on Windows, you'd want to design the API so that you can have either modal undo lists or a single interleaved undo list depending on local platform conventions

[11:08:50.0000] <rniwa>
smaug____: testing what?

[11:09:20.0000] <smaug____>
native apps and undo handling

[11:10:52.0000] <rniwa>
othermaciej: even on Mac, each text field has its own undo maanger

[11:11:01.0000] <rniwa>
othermaciej: because each text field is implemented as a seprate view.

[11:11:45.0000] <rniwa>
othermaciej: i'm open to amend the spec if you have a concrete proposal.

[11:44:48.0000] <jgraham>
rniwa: What's the state of running testharness.js/W3C tests in webkit?

[11:44:59.0000] <rniwa>
jgraham: it runs :)

[11:45:06.0000] <rniwa>
jgraham: testharness.js has been imported to WebKit

[11:45:16.0000] <rniwa>
jgraham: and W3C reftests are supported to some extent.

[11:45:28.0000] <rniwa>
jgraham: we're still discussing the process by which we import tests

[11:45:40.0000] <rniwa>
jgraham: we've found that we have to make a bunch of imporvements to our testing infrastrucutre first

[11:45:44.0000] <rniwa>
jgraham: in order to import more tests.

[11:45:54.0000] <jgraham>
I see

[11:46:16.0000] <rniwa>
jgraham: you can see some tests for regions and undo manager written using testharness.js already

[11:46:32.0000] <rniwa>
jgraham: those can be upstreamed directly to W3C repository

[11:49:50.0000] <othermaciej>
rniwa: do you mean each text field has its own undo manager in reality, or in your proposal?

[11:49:59.0000] <rniwa>
othermaciej: yes.

[11:50:04.0000] <rniwa>
othermaciej: in realitiy on mac

[11:50:08.0000] <othermaciej>
rniwa: when I open a test document with two <input type=text>, I get a single unified undo list

[11:50:22.0000] <rniwa>
othermaciej: on native Mac apps

[11:50:24.0000] <rniwa>
othermaciej: not on WebKit

[11:52:15.0000] <rniwa>
othermaciej: if you have text fields on Mac app, undos in each text field aren't usually put int a single undo stack.

[11:53:14.0000] <othermaciej>
rniwa: ok, I can repro that sort of, but what I actually see is that changing focus from one text field to another (e.g. in Mail prefs) wipes the undo stack

[11:53:27.0000] <othermaciej>
rniwa: in other words, switching focus back doesn't get you the old undo list

[11:54:33.0000] <rniwa>
othermaciej: that's a good point.

[11:54:54.0000] <othermaciej>
I don't know of any app where you truly have multiple independent undo lists in one window

[11:55:25.0000] <othermaciej>
I think the text field behavior may not be fully intended, I think it is an artifact of the fact that the real editable text field only exists temporarily while you have focus, and gets recycled when you change focus

[11:55:46.0000] <othermaciej>
WebKit doesn't have that issue which is why actually we let you undo across multiple fields

[11:55:57.0000] <rniwa>
othermaciej: possibly.

[11:56:03.0000] <rniwa>
othermaciej: but we can't have one undo manager per page

[11:56:13.0000] <rniwa>
othermaciej: that'll lead to the said cross-origin problem

[11:56:30.0000] <rniwa>
othermaciej: so we need to have at least one undo manager per document.

[11:56:36.0000] <othermaciej>
you pointed me to a security bug that said it might be a problem, but it didn't identify an actual problem

[11:57:00.0000] <othermaciej>
that being said, one per document is much closer to reasonable UI, and much saner to implement

[11:57:04.0000] <othermaciej>
so it would still be a big improvement

[11:57:08.0000] <rniwa>
othermaciej: the problem is that you can trigger undo/redo on a cross-origin document

[11:58:00.0000] <rniwa>
othermaciej: given that we have seamless iframe

[11:58:07.0000] <rniwa>
othermaciej: it might be okay.

[11:58:22.0000] <othermaciej>
right, and that seems bad in theory, but I'm not totally sure what the real danger of that is

[11:58:52.0000] <rniwa>
othermaciej: restricting undo manager to be per-document will solve a whole bunch of problems we've had.

[11:59:10.0000] <othermaciej>
security problems? or implementation problems?

[11:59:20.0000] <rniwa>
othermaciej: what is?

[11:59:30.0000] <othermaciej>
"restricting undo manager to be per-document will solve a whole bunch of problems we've had"

[11:59:34.0000] <othermaciej>
what kind of problems?

[11:59:44.0000] <rniwa>
othermaciej: reference cycle problem

[11:59:57.0000] <rniwa>
othermaciej: having to "disconnect" undo manager when the node moves from one place to another in the same document

[12:00:06.0000] <rniwa>
othermaciej: or having to adopt an undo manager from one document to another

[12:00:33.0000] <rniwa>
othermaciej: undoscope also depends on contenteditable because it doesn't make any sense to have multiple undo managers in the same editable region

[12:00:38.0000] <othermaciej>
oh, you mean relative to per-node

[12:00:54.0000] <rniwa>
othermaciej: that also adds a lot of complications for us because content-editability is specified by CSS in WebKit

[12:00:56.0000] <othermaciej>
I thought you meant per-document relative to per-top-level

[12:00:57.0000] <rniwa>
othermaciej: yeah.

[12:01:16.0000] <rniwa>
othermaciej: I'm saying that per-document is much better implementation wise

[12:01:22.0000] <rniwa>
othermaciej: it'll solve all sorts of problems we face

[12:01:30.0000] <othermaciej>
yeah, it's simpler to implement, and probably better in terms of user experience

[12:01:37.0000] <rniwa>
othermaciej: potentially.

[12:11:52.0000] <rniwa>
othermaciej: could you reply to the public-webapps thread we have?

[12:11:59.0000] <rniwa>
othermaciej: i breifly talked with ojan about this

[12:12:09.0000] <rniwa>
othermaciej: and we both agreed that we can just get rid of undoscope attribute

[12:12:12.0000] <othermaciej>
yeah, I can

[12:12:17.0000] <othermaciej>
/me adds a TODO item

[12:12:24.0000] <rniwa>
othermaciej: it simplieis a lot of thigns, and it seems like an overall win.

[12:31:26.0000] <TabAtkins>
D'oh, I hate responding to a very long well-intentioned suggestion email with "You're wrong in every way.  Sorry.".

[12:33:38.0000] <Hixie>
welcome to my life

[12:34:00.0000] <Hixie>
you start to get a large portfolio of ways to say "no"

[12:37:22.0000] <Hixie>
still no hsivonen about? is he on vacation or something? anyone know?

[12:41:41.0000] <jgraham>
Hixie: Pretty sure he is never here at this time even when he is about

[12:43:13.0000] <jgraham>
(the stats page confirms this)

[12:46:42.0000] <Hixie>
he's been idle for four days

[12:46:51.0000] <Hixie>
so i'm not sure regular hours apply :-)

[13:40:58.0000] <hober>
note to self: don't use *scratch* when generating editor boilerplate replies.

[13:42:20.0000] <jgraham>
You didn't manage to make the editor bilerplate valid elisp?

[13:42:47.0000] <jgraham>
+o

[14:31:24.0000] <Hixie>
TabAtkins: fallback leads to authors not noticing the problem which leads to more network traffic for lower quality results than the ideal result the author wanted

[14:31:57.0000] <TabAtkins>
Yeah, but lack of fallback means the user is punished by not having an image when a less-good substitute is available.

[14:32:10.0000] <TabAtkins>
(I'm for dropping the fallback, but the CSSWG wanted me to pursue requesting a change to HTML first.)

[14:32:28.0000] <TabAtkins>
These two positions appear to be the fundamental argument.

[14:32:38.0000] <TabAtkins>
It's what we settled into at the f2f.

[14:33:08.0000] <Hixie>
if the author sees the problem, they'll likely fix it, so the user will get the high quality image

[14:33:19.0000] <Hixie>
so no fallback seems net better for the user in the longer term

[14:33:21.0000] <TabAtkins>
Fallback = better user experience when there's a minor problem, No Fallback = less network traffic and better chance of noticing the problem.

[14:37:14.0000] <zewt>
are there script-visible effects from srcset that might change asynchronously if a fallback happens? (if so, that would be a significant complication)

[14:37:45.0000] <Hixie>
zewt: sure, the image dimensions would change

[14:37:59.0000] <Hixie>
technically btw the html spec allows fallback today, iirc

[14:38:01.0000] <zewt>
that would be very bad, I think (since it's one of those rare things that nobody would ever handle, even if we gave them a way)

[14:38:12.0000] <Hixie>
since you can arbitrarily decide to rerun the algorithm and arbitrarily pick anything from the list

[14:38:46.0000] <Hixie>
but that's just like technically the spec allows the UA to not show the image inline at all but to project it onto a second monitor with the colours reversed, or whatnot

[15:27:25.0000] <TabAtkins>
zcorpan: Added the rect() quirk to the doc as well.

[16:00:45.0000] <Hixie>
so svn blame tells me what revision a line was added in

[16:00:50.0000] <Hixie>
is there some way to find out when it was removed?

[16:00:59.0000] <Hixie>
a kind of reverse blame?

[16:16:41.0000] <TabAtkins>
Oh jeez, view this in WebKit: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1706

[16:16:48.0000] <TabAtkins>
Uninitialized memory reads ahoy!

[16:30:58.0000] <hober>
TabAtkins: ooof. what's the bug #?

[16:31:08.0000] <TabAtkins>
esprehn is working on it already, I think.

[16:31:22.0000] <TabAtkins>
He showed me the problem a few minutes ago.

[16:43:42.0000] <gavinc>
/me boggles, "Anyone every heard of chrome consolidating ajax POST requests?"

[16:58:42.0000] <gavinc>
Click 10 times, 10 events fired, only 3 requests really made. Now THAT in unexpected.


2012-08-22
[17:00:20.0000] <Hixie>
o_O

[17:01:49.0000] <gavinc>
I think I have to remove some variables (using JQuery) and make this test case just use XHR, but seriously WTF

[17:45:42.0000] <Hixie>
MikeSmith: component watching used to be done years ago by having a component QA and then having people watching that component QA

[17:45:53.0000] <Hixie>
MikeSmith: that requires account watching to be enabled, though

[00:57:46.0000] <zcorpan>
TabAtkins: excellent. looks correct now afaict. thanks. i'll remove the quirks from quirks mode spec

[03:08:02.0000] <jgraham>
Huh, why am I having so much difficulty making chrome prompt me to stay on a page by using a beforeunload event?

[03:16:36.0000] <zcorpan>
TabAtkins: the asyncness of CAS means that there's a race condition -- elements might be parsed before the CAS is loaded, and do their thing (like, load something) before the CAS kicks in

[03:17:22.0000] <zcorpan>
i think we have enough trouble with race conditions as it is

[03:39:43.0000] <odinho>
jgraham: Isn't that stuff disabled for those? Was some talk about it at least.

[03:40:42.0000] <zcorpan>
prompting to stay is the reason beforeunload exists

[03:41:20.0000] <odinho>
zcorpan: Maybe it was unload if that is an event.

[03:41:33.0000] <zcorpan>
yeah

[03:46:00.0000] <jgraham>
I eventually fixed up the problem

[03:46:14.0000] <jgraham>
Firefox doesn't seem to prompt with history.go

[03:46:35.0000] <jgraham>
Chrome didn't like it when I used a function from a different document as the event handler

[03:46:51.0000] <jgraham>
(I don't think)

[03:46:56.0000] <jgraham>
(which seems like a bug)

[03:47:04.0000] <jgraham>
Well one bug each

[04:00:20.0000] <jgraham>
Oh, I lied gecko didn't have that bug

[04:00:32.0000] <jgraham>
So now I wonder if I was doing something strange

[05:09:33.0000] <ruby_on_tails>
hello

[05:09:50.0000] <ruby_on_tails>
if i draw an arc in canvas it starts from the rightmost, how can i make it start from the top

[07:23:04.0000] <crankharder>
I'm having a problem with the application cache in chrome.  My app cache looks like this: https://gist.github.com/3426029  Once this has been loaded, the fallback section takes over for all non-200 responses, which means that in all error conditions (4/500), my app falls back to /offline, which is not expected behavior. Should this not be happening, or is there some way to avoid it?

[07:25:05.0000] <crankharder>
As "/ /offline" is a typical example in the docs, I can't imagine that it is recommended to circumvent all non-200 requests while the user is online.

[08:12:08.0000] <jgraham>
OK, now I know what tool I need for the spec

[08:12:23.0000] <jgraham>
I want something that marks up bugs filed on different bits of the spec

[08:12:43.0000] <jgraham>
So when someone submits a bug on a specific section everyone can see it

[08:13:28.0000] <zcorpan>
yes, bug annotations would be great

[08:14:43.0000] <jgraham>
I need this so much, jsut to track bugs that *I* filed I think I will have to implement it

[08:15:34.0000] <zcorpan>
\o/

[08:28:33.0000] <Ms2ger>
\o/

[08:37:47.0000] <jgraham>
Hmm, so I guess it would be useful to remove bugs once they are closed. Which means that having bzAPI on W3C bugzilla would be rather helpful

[08:37:52.0000] <jgraham>
MikeSmith: ^

[08:54:52.0000] <jgraham>
Hixie: Can I get the bug filing / status updating CGI scripts?

[09:24:40.0000] <MikeSmith>
jgraham: I wasn't aware that bugs could be removed

[09:24:53.0000] <Ms2ger>
MikeSmith, closed

[09:25:04.0000] <Ms2ger>
Then they shouldn't be listed in the in-spec annotations

[09:25:24.0000] <MikeSmith>
ah

[09:25:50.0000] <MikeSmith>
/me tries to recall previous discussions about bzAPI

[09:26:40.0000] <MikeSmith>
is it not already enabled?

[09:26:47.0000] <jgraham>
MikeSmith: Myabe?

[09:27:01.0000] <jgraham>
I didn't actually try, I just assumed it wasn't

[09:27:10.0000] <MikeSmith>
ah I think it's not

[09:27:22.0000] <MikeSmith>
because v1 was released in 2011

[09:27:35.0000] <MikeSmith>
and we are running 3.6 from 2010

[09:27:40.0000] <MikeSmith>
and it's an add-on I guess

[09:29:13.0000] <jgraham>
Yeah it's an addon. but it seems to be 3.6.x compatible

[09:29:19.0000] <jgraham>
At least for some value of x

[09:30:35.0000] <MikeSmith>
ok

[09:40:44.0000] <Ms2ger>
MikeSmith, I am told it does indeed support 3.6

[09:40:55.0000] <MikeSmith>
OK

[10:39:17.0000] <Hixie>
jgraham left :-(

[10:39:37.0000] <Hixie>
oh, no, it was just a netsplit!

[10:39:37.0000] <Hixie>
jgraham: ping

[10:46:33.0000] <jgraham>
Hixie: pong

[10:46:51.0000] <Hixie>
jgraham: i like your idea and wish to subscribe to your newsletter

[10:47:10.0000] <jgraham>
Heh

[10:48:03.0000] <Hixie>
jgraham: the way i've been doing similar things for my internal e-mail management is that i have a cronjob that just loads each bug one at a time and compares their current state, deleting e-mails relating to bugs not assigned to me or that are not closed

[10:48:07.0000] <Hixie>
jgraham: and so on

[10:48:33.0000] <Hixie>
jgraham: seems like we can do something similar here, just walking the bug list and reading the initial description of each one to get the section ID

[10:48:44.0000] <Hixie>
with some local caching to avoid hammering bugzilla it should be pretty simple to do

[10:48:59.0000] <Hixie>
(since you can just do a query to get the buglist, and then you only need to load the new bugs, bugs can't change section)

[10:49:17.0000] <jgraham>
Hixie: I was thinking that you would just hook up the bug submission thing to give you the initial list of bug ids

[10:49:42.0000] <jgraham>
But of course if you can get it from the actual bug data that would be better

[10:49:53.0000] <Hixie>
yeah you can totally just grab the comments and walk through them

[10:49:58.0000] <Hixie>
that's how i did the cloning, e.g.

[10:50:17.0000] <Hixie>
(bugzilla has an xml output mode)

[10:50:23.0000] <Hixie>
(so there's no scraping to do)

[10:50:45.0000] <jgraham>
Oh, that helps

[10:51:05.0000] <Hixie>
for both the query results and the bug data

[10:51:22.0000] <Hixie>
how were you thinking of exposing the data?

[10:51:31.0000] <Hixie>
simplest way for me is to just call a script on your domain and have you do whatever you want

[10:52:10.0000] <jgraham>
Exposing in what way? In the UI?

[10:52:13.0000] <Hixie>
yeah

[10:52:34.0000] <jgraham>
I was thinkking it should be part of the status annotations

[10:52:56.0000] <Hixie>
that works

[10:53:19.0000] <Hixie>
i can provide an API for you to hook into if you want, or we can do it all server-side and just have the status things come out of the database

[10:53:31.0000] <Hixie>
server side meaning you push teh data straight into the database rather than on each page load

[10:53:57.0000] <Hixie>
API meaning in the script

[10:54:18.0000] <Hixie>
i guess for you it's lighter load to do it via server-side comms

[10:54:26.0000] <Hixie>
and let me deal with the UI

[10:54:29.0000] <jgraham>
Yeah, that makes sense to me

[10:54:32.0000] <Hixie>
k

[11:00:20.0000] <jgraham>
OK, I can write the code to grab the data. What do I need to do to push it into the database?

[11:01:55.0000] <Hixie>
have your script output the data in the form  "sectionid bugid bugid bugid\nsectionid bugid bugid\nsectionid bugid"

[11:02:07.0000] <Hixie>
i'll provide you a secret URL to POST to that will update teh DB

[11:05:20.0000] <jgraham>
So each time it will provide all the bug ids, and bugs that got resolved will be removed from the db on your end?

[11:21:26.0000] <Hixie>
jgraham: sounds good

[12:06:04.0000] <Hixie>
jgraham: should i store bug IDs, or bug URLs?

[12:06:33.0000] <Hixie>
jgraham: because another way i could do this would be just to change the current "demos" feature to a "bugs" feature

[12:06:40.0000] <Hixie>
jgraham: since we don't use the "demos" feature

[12:06:48.0000] <Hixie>
jgraham: this would also allow other people to add bugs and stuff

[12:07:07.0000] <Hixie>
jgraham: i guess it's easier to just have a list of IDs and not make it editable

[12:13:04.0000] <jgraham>
Hixie: I think have a list of IDs and if people want to edit it they can add a string like the one that the bug script produces as a comment in the bug

[12:15:35.0000] <Hixie>
makes sense

[12:16:09.0000] <Hixie>
hopefully nobody abuses it; if they do we can always have some specific people whitelisted who can use a "cancel" magic word :-)

[12:33:16.0000] <Hixie>
ok 33% complete on my end: the database has a bugs table and the cgi script passes the data to the client

[12:33:19.0000] <Hixie>
no way to add to it yet...

[12:34:12.0000] <jgraham>
I guess I will finish my end tomorrow; am feeling kind of sleepy now

[12:34:58.0000] <jgraham>
But it is coming together

[12:36:55.0000] <Hixie>
cool

[12:37:23.0000] <Hixie>
let me know if you need any help figuring out how to get xml out and stuff, or how the schema they use works, i still remember it all from doing the cloning

[12:51:22.0000] <Hixie>
is it me or is today a bad spam day

[13:24:30.0000] <hober>
Hixie: do you manually approve ml subscriptions?

[15:04:50.0000] <Hixie>
hober: no

[15:05:07.0000] <Hixie>
hober: why?

[15:11:03.0000] <hober>
Hixie: just wondering. a coworker's subscription took longer than he thought it would; probably just an email hiccup

[15:19:47.0000] <Hixie>
hober: weird

[15:20:08.0000] <Hixie>
hober: the only moderation action i take is with messages > 40kb, and those i mostly only allow if they're mine :-)

[15:20:15.0000] <hober>
*nod*

[15:20:39.0000] <Hixie>
(those that aren't usually are 40kb of quoted content with top-posting, which is against the mailing list etiquette)

[15:21:03.0000] <Hixie>
anyone remember what the bug is where i talked about appcache having a js-driven "server"?

[15:21:07.0000] <Hixie>
i can't find it

[15:34:59.0000] <Hixie>
Truncation operations cannot be performed if the session holds an active table lock

[15:35:03.0000] <Hixie>
wtf

[15:36:31.0000] <Hixie>
well, i guess jgraham better not ever call this reentrantly

[16:11:15.0000] <Hixie>
jgraham: ok, server-side is done, now working on client side.

[16:22:42.0000] <jacobolus>
re: http://www.w3.org/TR/compositing/#blendingnonseparable

[16:23:10.0000] <jacobolus>
is there some reason why Photoshop’s arbitrary and idiosyncratic compositing modes are being copied?

[16:24:17.0000] <Hixie>
jacobolus: because the editor is from adobe? :-)

[16:24:21.0000] <Hixie>
(client-side done as well, now i just have to debug it all...)

[16:24:57.0000] <jacobolus>
Hixie: I mean, I guess this is great if someone wants to use a browser to preview PSD documents

[16:25:30.0000] <jacobolus>
but these blend modes are based on what could be done quickly on early-1990s computer hardware

[16:25:51.0000] <Hixie>
you have to ask the editor

[16:25:52.0000] <zewt>
many of photoshop's blending modes are useful and if they're going to put them all under a patent disclaimer then cool, go for it

[16:26:19.0000] <Hixie>
(i don't think rik hangs out here)

[16:26:58.0000] <jacobolus>
doing a sum of .30 * R + .59 * G + .11 * B, for gamma-adjusted R, G, B, is based on the primaries used in the Adobe RGB space

[16:27:26.0000] <jacobolus>
but only actually properly yields luminance for linear RGB, not gamma adjusted

[16:27:50.0000] <Hixie>
it seems unsurprising to me that a spec from someone at adobe would be based on adobe's stuff...

[16:27:55.0000] <zewt>
(it's also the most useful thing if you're handed a PSD from an artist using random blend modes and told to recreate it dynamically)

[16:28:04.0000] <jacobolus>
the word “luminance” is something that was made up by Adobe, is given several incompatible definitions in photoshop, and has no external technical meaning

[16:28:47.0000] <jacobolus>
and their definition of “saturation” here is also not used the same way in any other context

[16:28:47.0000] <zewt>
(hint: opengl uses it all over the place)

[16:28:59.0000] <zewt>
(also hint: complaining in here isn't going to do anything :)

[16:29:08.0000] <jacobolus>
opengl is also based on early-1990s photoshop? bleh.

[16:30:20.0000] <Hixie>
if you just want to get it off your chest, please do go on, ranting here is always welcome. :-) but as zewt says, if you want to affect the spec, your time may be better spent e-mailing the spec's editor or the lists mentioned in the spec's status section

[16:30:39.0000] <Hixie>
(please don't take this as a suggestion to shut up though)

[16:30:43.0000] <jacobolus>
:)

[16:31:16.0000] <jacobolus>
I guess I don't really care what goes in the spec. not like there isn't plenty of other legacy garbage in the web tech stack

[16:31:36.0000] <cabanier>
hey

[16:31:49.0000] <othermaciej>
jacobolus: I don't really fully understand blend modes or why they are separate from compositing operators

[16:31:50.0000] <cabanier>
you don't like the spec?

[16:32:15.0000] <jacobolus>
othermaciej: those two terms are synonyms in most contexts :)

[16:32:26.0000] <jacobolus>
othermaciej: “blend mode” is photoshop’s word for it

[16:32:28.0000] <othermaciej>
jacobolus: well, not in this spec or in photoshop

[16:32:31.0000] <othermaciej>
they are sort of orthogonal

[16:32:40.0000] <jacobolus>
..?

[16:32:41.0000] <othermaciej>
(maybe I am wrong about photoshop)

[16:32:51.0000] <cabanier>
read the specification. It talks why they are different

[16:33:01.0000] <othermaciej>
you can have a blend mode of multiply and a compositing operator of dest-atop

[16:33:04.0000] <cabanier>
blending = how colors combine

[16:33:12.0000] <cabanier>
compositing = how you treat alpha

[16:33:31.0000] <Hixie>
oh hey, rik _does_ hang out here

[16:33:32.0000] <Hixie>
go figure!

[16:33:34.0000] <Hixie>
hey rik!

[16:33:36.0000] <cabanier>
:-)

[16:33:38.0000] <jacobolus>
othermaciej: fine. that's kind of irrelevant to my point, and that's a kind of idiosyncratic set of definitions, but it's no big deal

[16:33:46.0000] <zewt>
(also it's 2012, can we not put "1.0" at the end of spec names)

[16:33:49.0000] <Hixie>
jacobolus: i take it back, ranting here is productive after all :-)

[16:33:54.0000] <othermaciej>
a blend function takes src and dest color components as input, and gives a color (ignoring alpha) as output

[16:34:14.0000] <othermaciej>
so Cblended = B(Cs, Cd)

[16:34:23.0000] <othermaciej>
compositing functions also take into account alpha

[16:34:38.0000] <othermaciej>
so Ccomposited = C(Cs, As, Cd, Ad)

[16:34:56.0000] <othermaciej>
and if you have both, then you use the blend output as the source input to the compositing operator

[16:35:20.0000] <othermaciej>
which strikes me as somewhat weird

[16:35:21.0000] <jacobolus>
othermaciej: okay, let me rephrase my original comment then... is there some reason why Photoshop’s arbitrary and idiosyncratic compo^H^H^H^H^Hblend modes are being copied?

[16:35:24.0000] <cabanier>
yes

[16:35:42.0000] <cabanier>
they are widely implemented

[16:36:00.0000] <othermaciej>
jacobolus: I find the whole thing mysterious, but I am not enough of a graphics expert to know if there is a better approach to this sort of thing, or if this is the industry standard

[16:36:02.0000] <zewt>
jacobolus: another hint: everyone who works long in graphics (of any type, including ui) has an understanding of them

[16:36:02.0000] <cabanier>
PDF, Skia, coregraphics, win8 direct2d,

[16:36:13.0000] <cabanier>
Firefox

[16:36:16.0000] <cabanier>
etc

[16:36:30.0000] <jacobolus>
cabanier: "luminosity", "hue", "color" etc. modes are implemented all those places?

[16:36:30.0000] <cabanier>
they were also in the SVG spec (but were never implemented)

[16:36:38.0000] <jacobolus>
I find that hard to believe

[16:36:48.0000] <cabanier>
core graphic and win8 has them for sure

[16:37:01.0000] <jacobolus>
okay, apparently they're in PDF

[16:37:30.0000] <cabanier>
What is it that you don't like about them?

[16:37:32.0000] <zewt>
implemented color burn and several others in opengl a long time ago, heh https://svn.stepmania.com/svn/trunk/stepmania/Data/Shaders/GLSL/Color%20burn.frag

[16:37:39.0000] <jacobolus>
cabanier: they're arbitrary and produce bad results

[16:37:42.0000] <cabanier>
Designers already know about them

[16:38:04.0000] <cabanier>
standard teaching in design schools

[16:38:12.0000] <jacobolus>
they should have been fixed in photoshop as soon as the hardware could keep up, which was about 10 years ago

[16:38:32.0000] <cabanier>
jacobolus: do you have more info? Why do they produce bad results?

[16:38:37.0000] <jacobolus>
now unfortunately people are going to be stuck with technical choices made for the constraints of 20 years ago, into the foreseeable future

[16:38:50.0000] <Hixie>
like 80 character line length limits? :-D

[16:38:56.0000] <zewt>
Hixie: *rage*

[16:38:59.0000] <cabanier>
they were introduced in 98 or so

[16:39:12.0000] <Hixie>
zewt: but what if i want to save my code to punchcard!!!!

[16:39:13.0000] <cabanier>
please let me know if you have a better idea

[16:39:14.0000] <jacobolus>
cabanier: because .30R + .59G + .11B, when R, G, and B are gamma-adjusted sRGB, is an entirely nonsensical quantity

[16:39:25.0000] <zewt>
(if I see one more person writing python in 80-columns because they unquestioningly followed the drek that is PEP-8 i will launch them into space)

[16:40:08.0000] <gavinc>
ASCII being the most annoying, like no one thought maybe Iñtërnâtiônàlizætiøn would be important

[16:40:18.0000] <cabanier>
so, you don't like the non-separable ones?

[16:40:32.0000] <jacobolus>
they don't correspond to human vision, they don't correspond to any technical device

[16:40:46.0000] <jacobolus>
they're quantities made up by adobe for the constraints of early 1990s computers

[16:40:55.0000] <cabanier>
it's a reasonable formula.

[16:41:02.0000] <jacobolus>
no, it's not a reasonable formula

[16:41:15.0000] <cabanier>
As long as everyone implements it the same, the designer's choice will look the same

[16:41:18.0000] <jacobolus>
it's a formula that tells people (by the names used) that it's doing one thing, while in fact it does another

[16:41:25.0000] <cabanier>
there is no arguing about color math

[16:41:36.0000] <jacobolus>
that's great. but it sucks for all the designers involved, who end up with unintuitive dreck

[16:41:53.0000] <cabanier>
you think they are doing the math in their heads?

[16:41:54.0000] <zewt>
jacobolus: the point is that artists want something to look a certain way, and they use blend functions to achieve the look they want; that's their primary purpose

[16:42:07.0000] <cabanier>
they just used their tools/browsers until they like what they see

[16:42:10.0000] <jacobolus>
zewt: you got it. but my point is, what they want is not actually what they're getting

[16:42:35.0000] <zewt>
they're looking at what they're getting and going "yep. looks like what I want." which means they have what they want. that's really how it works :)

[16:42:51.0000] <jacobolus>
zewt: I mean, okay, in some sense that's true

[16:43:05.0000] <zewt>
it's the basic gap between artistic design and technical design

[16:43:30.0000] <cabanier>
people don't like that you muck with their colors. Adobe has made that mistake in the past.

[16:43:31.0000] <jacobolus>
it's a basic gap caused by shitty programming, because the dimensions involved don't correspond to human vision

[16:43:43.0000] <gavinc>
jacobolus: err, I don't think those are Adobe's those at least look like sRGB's numbers

[16:44:01.0000] <cabanier>
We've given up on most of the complex color math if you use default setting

[16:44:01.0000] <jacobolus>
gavinc: they're based on the primaries used by the Adobe RGB color space

[16:44:11.0000] <jacobolus>
gavinc: but don't make any sense for gamma-corrected components

[16:44:18.0000] <gavinc>
jacobolus: Are you sure? Those look like the primaries for sRGB

[16:44:32.0000] <jacobolus>
gavinc: yes, I'm sure

[16:44:39.0000] <gavinc>
jacobolus: okay :D

[16:45:09.0000] <jacobolus>
gavinc: the equivalents for the primaries used by sRGB would be .21 * R + .72 * G + .07 * B

[16:45:21.0000] <gavinc>
jacobolus: ah, yes. my mistake

[16:46:31.0000] <zewt>
(no, the gap between technical and artistic work is that one generally has a "right answer" and the other is entirely subjective; this applies fairly universally)

[16:47:47.0000] <jacobolus>
zewt: if I sat you down with image editing software that was properly based on human-relevant color dimensions, and then put you back on current software, you'd throw a fit, because there is a night and day difference

[16:48:03.0000] <cabanier>
jacobolus: please post on www-style if you have ideas on making the spec better.

[16:48:14.0000] <jacobolus>
cabanier: I think it's a lost cause

[16:48:14.0000] <Hixie>
were there people other than hsivonen who were against the way <template> parses into a separate doc?

[16:48:19.0000] <cabanier>
jacobolus: we've been there. everyone hated it

[16:48:55.0000] <cabanier>
jacobolus: the vast majority of people didn't understand it

[16:49:07.0000] <cabanier>
jacobolus: hardly anyone could print it

[16:49:11.0000] <jacobolus>
cabanier: basically, the quick decisions made by some guys at adobe one afternoon are destined to live on to eternity :)

[16:49:29.0000] <jacobolus>
what is "it"?

[16:49:41.0000] <jacobolus>
people didn't understand what?

[16:50:12.0000] <zewt>
jacobolus: maybe, maybe not--it doesn't matter because every artist I've ever worked with uses PS and expects output to be what they see

[16:50:19.0000] <cabanier>
jacobolus: device independent workflows. Everything icc based

[16:50:24.0000] <cabanier>
zewt: exactly!

[16:50:34.0000] <jacobolus>
cabanier: what does ICC profiles have to do with anything?

[16:50:42.0000] <zewt>
cabanier: btw. no vivid light? heh

[16:50:55.0000] <zewt>
(guess it's been a long time since I've been handed a PSD using that)

[16:51:02.0000] <jacobolus>
for anyone keeping score, I drew some nice diagrams and so forth at http://en.wikipedia.org/wiki/HSL_and_HSV which calls the dimensions involved in these blend modes “chroma” and “luma”

[16:51:21.0000] <jacobolus>
though again, those aren't ideal names

[16:51:22.0000] <cabanier>
zewt: I keep asking people if they want all the PS blend modes but I get no feedback

[16:52:14.0000] <zewt>
https://svn.stepmania.com/svn/trunk/stepmania/Data/Shaders/GLSL/Vivid%20light.frag don't recall what effect i implemented that for, though

[16:53:01.0000] <jacobolus>
cabanier: do you have any ins w/ people working on photoshop? can you tell them to add "exclusion" blend mode for files in CIELAB mode?

[16:53:34.0000] <jacobolus>
the combination of linear light mode + exclusion mode is one of the most powerful tools in photoshop (albeit entirely unused by anyone)

[16:54:34.0000] <gavinc>
possibly horribly wrong statement: I'm pretty sure .30R + .59G + .11B is a great deal older then anything at Adobe my memory (which has already proved faulty) is that it's from YUV used in PAL and NTSC but I may be totally wrong on that, my color math is bit a rusty and was mostly for print

[16:56:09.0000] <cabanier>
From the postscript (!) manual: the gray value for a given RGB value is computed according to the NTSC video standard. This standard determines how a color television signal is rendered on a black-and-white television set.

[16:56:17.0000] <gavinc>
Okay, NOT crazy

[16:56:33.0000] <cabanier>
you were right on! impressive!

[16:56:36.0000] <jacobolus>
gavinc: NTSC and Adobe RGB use similar primaries

[16:56:46.0000] <jacobolus>
not quite identical

[16:57:31.0000] <jacobolus>
gavinc: but that's beside the point

[16:57:59.0000] <jacobolus>
which is that images on the web are specified to be sRGB

[16:58:18.0000] <jacobolus>
and that adding linear combinations of gamma-encoded quantities yields nonsensical results

[16:58:59.0000] <gavinc>
okay, I think I mostly agree with that. But would need to put a great deal more color math back in my head before agreeing fully


2012-08-23
[17:01:28.0000] <jacobolus>
also, max(R, G, B) - min(R, G, B) is an extremely bad proxy for the perceived attribute chroma (which is similar to saturation, but the two have different technical definitions)

[17:02:19.0000] <zewt>
(if these don't match PS then I'd probably never use them, because they'd be incompatible with every art asset our artist hands me)

[17:03:10.0000] <jacobolus>
zewt: it's a sad world, right? Adobe can never change their software, because it wouldn't be backward compatible. everyone else has to copy photoshop, or it wouldn't be interoperable

[17:03:35.0000] <jacobolus>
zewt: and so technical decisions that make no sense in 2012 are entirely impossible to change, ever

[17:03:42.0000] <cabanier>
jacobolus: people don't want us to change it. There would be an all-out revolt.

[17:03:50.0000] <zewt>
it makes perfect technical sense, in the context of the real world

[17:04:38.0000] <jacobolus>
it's just sad, because color is a place where these decisions actually negatively impact every user who tries to create images with them

[17:04:42.0000] <cabanier>
jacobolus: we can add things

[17:04:53.0000] <jacobolus>
a lot of technical decisions can be papered over and never seen by the user

[17:05:19.0000] <cabanier>
jacobolus: like I said, with color, with pulled most of the features because everyone hated it and turned it off

[17:05:20.0000] <zewt>
(yet there's been no revolt when photoshop changed to stop allowing the navigator to navigate outside the border of the image, which screwed up a bunch of my usage habits; maybe I can pay a mob to revolt for me)

[17:05:44.0000] <cabanier>
jacobolus: turning it off was harder than the math. A lot of special case code

[17:05:55.0000] <jacobolus>
zewt: oh really? that was one of my favorite photoshop changes of all time :)

[17:06:20.0000] <zewt>
it's horrible; I used it all the time to edit around the edge, now it's impossible to even see the edge of the image that way (since it falls underneat the toolbars)

[17:06:22.0000] <jacobolus>
cabanier: I don't know what specifically you're talking about here

[17:06:24.0000] <zewt>
also underneath

[17:06:40.0000] <jacobolus>
zewt: wait, what?

[17:06:47.0000] <jacobolus>
zewt: dude, press the "F" key

[17:07:00.0000] <zewt>
i work in fullscreen 100% of the time

[17:07:05.0000] <jacobolus>
zewt: sorry, I thought you meant the change the other direction

[17:07:22.0000] <zewt>
did they fix that in cs6 or something?

[17:07:53.0000] <jacobolus>
could you move past the corners in a document in a window, ever?

[17:08:03.0000] <zewt>
definitely ... up until something like cs2

[17:08:18.0000] <jacobolus>
oh, bummer

[17:08:20.0000] <zewt>
(and you still can by manually dragging around, the navigator just clips at the edge)

[17:08:41.0000] <jacobolus>
yeah, that's terrible

[17:09:09.0000] <cabanier>
jacobolus: I'm technically still on the photoshop team. I can ask them why that decision was made.

[17:09:34.0000] <jacobolus>
zewt: for some reason I remember that one of the two fullscreen modes used to not to past the edge. but I could be inventing that in my head

[17:09:59.0000] <jacobolus>
cabanier: doesn't really affect me, but apparently zewt didn't like it :)

[17:10:14.0000] <jacobolus>
cabanier: if you can bug them about exclusion mode in CIELAB images though... :)

[17:11:02.0000] <jacobolus>
cabanier: also, if you're working on this css compositing spec, you should add 'linear light' mode if it can be easily done

[17:11:03.0000] <cabanier>
jacobolus: I will do so. there must be a reason that they grayed it out

[17:11:25.0000] <cabanier>
jacobolus: ask for it on www-style.

[17:11:29.0000] <jacobolus>
cabanier: the reason is that it's not thought to be meaningful for A/B channels, since they never get close to the extremes

[17:11:55.0000] <jacobolus>
and so combining two arbitrary images ends up with uninteresting looking results

[17:12:02.0000] <cabanier>
have to go...

[17:12:11.0000] <zewt>
run, run, run

[17:12:19.0000] <jacobolus>
cabanier: but exclusion mode is a building block, not a tool to be used alone

[17:12:35.0000] <jacobolus>
cheers

[17:12:49.0000] <jacobolus>
cabanier: anyway, linear light mode. pretty much my favorite blend mode after "normal"

[17:15:12.0000] <jacobolus>
gavinc: you're right, it's the Rec 601 primaries (NTSC) used for this formula, now that I think back about it

[17:15:50.0000] <gavinc>
yay, so it wasn't a choice made in the 90s! It's a choice made in the 70s!

[17:16:45.0000] <jacobolus>
I don't think there was any software image compositing in the 70s

[17:17:00.0000] <jacobolus>
still a choice made in the 90s :)

[17:17:23.0000] <jacobolus>
well, actually of course there was software image compositing in the 70s

[17:17:37.0000] <jacobolus>
but I don't think with these particular "blend modes" anyhow

[17:17:54.0000] <jacobolus>
anyway, I gotta run too

[17:18:03.0000] <jacobolus>
Hixie: sorry to crud up your channel there for a bit

[17:18:05.0000] <jacobolus>
:)

[21:44:54.0000] <MikeSmith>
Hixie: I think there was at least one person other than hsivonen who wasn't happy with the proposed <template> parsing

[21:45:04.0000] <MikeSmith>
/me goes to look back at some threads

[21:45:14.0000] <Hixie>
if it's me it doesn't count :-)

[21:45:21.0000] <MikeSmith>
hahaha

[21:58:29.0000] <MikeSmith>
Hixie: not exactly an answer to your question, but I think Scott Gonzalez questioned whether we need a <template> element at all, or need to be trying to do this through markup

[21:58:39.0000] <Hixie>
url?

[21:58:50.0000] <Hixie>
if he has an alternative solution that is certainly a good thing to look at

[22:00:53.0000] <MikeSmith>
Hixie: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0294.html

[22:01:27.0000] <MikeSmith>
he's scott_gonzalez on IRC

[22:01:36.0000] <MikeSmith>
dunno what timezone he's in

[22:01:43.0000] <MikeSmith>
maybe US/West or Central

[22:01:45.0000] <Hixie>
i think those points have been pretty fully explained by dimitry and company

[22:01:50.0000] <MikeSmith>
OK

[22:02:09.0000] <MikeSmith>
yeah I remember ojan replying

[22:02:52.0000] <MikeSmith>
anyway I guess Scott is the other person I was thinking of

[22:03:10.0000] <Hixie>
k

[22:04:08.0000] <Hixie>
<template> has bubbled its way to the top of my queue again but i'm not sure what to do since it seems a bit bad to go behind hsivonen's back on this

[22:04:22.0000] <Hixie>
especially after just having gone a way hsivonen didn't really want with the alt attribute thread

[22:04:57.0000] <Hixie>
though at least in that case it was just a naming thing

[22:05:06.0000] <Hixie>
this one is reather more... fundamental

[22:07:50.0000] <MikeSmith>
Hixie: I expect hsivonen will be back soon

[22:08:02.0000] <MikeSmith>
seems like he's been away for 3 weeks or so already

[22:09:22.0000] <Hixie>
that's what i thought a few days ago, which is why i had waited on the alt thing :-)

[22:30:42.0000] <zcorpan>
work on this until he's back :-) https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=anywordssubstr&short_desc=%3Ctrack%3E+webvtt&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2

[22:30:43.0000] <zcorpan>
=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

[22:54:18.0000] <jacobolus>
cabanier: hey Rik. By the way, I wanted to say that even though I got a bit ranty earlier, I do appreciate the addition of more kinds of image compositing to CSS. It should enable some very cool stuff. :)

[22:55:27.0000] <jacobolus>
my annoyance at the "luminosity", etc. blend modes is with their technical details (which fall short of what they could be), not with their concept (which is a great one)

[22:56:21.0000] <jacobolus>
and even just directly copying photoshop's behavior, though perhaps not ideal, is definitely better than not having such features

[23:24:59.0000] <jgraham>
Hixie: It you are looking for things to do I certianly have reported bugs that I would like fixes for ;)

[23:26:20.0000] <jgraham>
In related news, I got an apparently working script last night so I will finish it up when I get to the office. Let me know whatever I need to interact with your end (if you didn't already, I didn't check email)

[23:27:26.0000] <Hixie>
jgraham: i sent you mail

[23:27:33.0000] <jgraham>
I was thinking of providing a URL that would respond to GETs that would cause an immediate update of the data (with some rate limiting to protect bugzilla)

[23:28:09.0000] <jgraham>
For long values of immediate (i.e. it would actually do the update async and call back to update your end)

[23:28:15.0000] <Hixie>
when would i call it?

[23:28:24.0000] <jgraham>
After someone submits a bug

[23:28:33.0000] <Hixie>
sure, i can do that

[23:28:44.0000] <Hixie>
not all bugs go through my script though

[23:29:31.0000] <jgraham>
Sure, but it would allow a slower update frequency whilst still getting mostly-fresh data

[23:29:57.0000] <jgraham>
Anyway, need to get ready to leave for the office now if I want to take the bus

[23:30:06.0000] <Hixie>
k

[23:30:24.0000] <Hixie>
if you want to do that (which is fine by me) reply to that e-mail and i'll hook in tomorrow at work

[23:30:56.0000] <jgraham>
Sure

[23:41:00.0000] <rniwa>
jezz... people are still talking about longdesc :(

[23:42:21.0000] <zcorpan>
longdesc! longdesc for img, longdesc for iframe, longdesc for video! everyone gets a longdesc!

[23:42:42.0000] <rniwa>
zcorpan: i propose we add longdesc element and add longdesc content attribute on that.

[23:43:52.0000] <jgraham>
rniwa: In web standards, the definition of "n00b" is "has endured less than half a decade of longdesc flamewars"

[23:44:24.0000] <rniwa>
jgraham: i had been following the w3c standards for a while but i had never been aware of longdesc flamewars :(

[23:44:34.0000] <rniwa>
jgraham: probably because i had avoided joining mailing lists

[23:44:55.0000] <jgraham>
rniwa: n00b

[23:45:13.0000] <jgraham>
:)

[23:45:49.0000] <rniwa>
jgraham: i must say i'm quite amazed that people participating in that discussion can make living...

[23:47:49.0000] <rniwa>
jgraham: although... on the other hand, the definition of standards n00b might be to consider W3C as too bureaucratic.

[23:48:10.0000] <rniwa>
jgraham: W3C is nothing like IETF or ISO.

[23:59:21.0000] <zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17273#c6 so use case A, i'm pondering about what an api would look like and have trouble with naming

[00:00:40.0000] <zcorpan>
my idea is: video.XYZ.add(0, 90, 100, 100); would occupy the bottom 10% of the video (so cues are pushed upwards) and video.XYZ.clear(); would clear the areas

[00:01:26.0000] <zcorpan>
having a property XYZ instead of putting the methods on video directly my thinking is that it would be easier to extend in the future and maybe easier to work with if you save the object as a variable

[00:02:14.0000] <zcorpan>
anyone have suggestions for the name?

[00:12:34.0000] <zcorpan>
video.viewport.occupy(...) maybe?

[00:33:32.0000] <odinho>
occupy video movement? :P

[00:34:01.0000] <jgraham>
video.viewport.occupy(99%)?

[00:34:18.0000] <odinho>
jgraham: Oh man, too good :D :D

[01:14:27.0000] <kennyluck>
So there's no longer WHATWG weekly….

[01:15:23.0000] <kennyluck>
For what it's worth, I do appreciate Anne's work. I can see how boring writing such summaries is…

[01:18:19.0000] <Ms2ger>
Do I hear a volunteer? :)

[01:18:41.0000] <jgraham>
Pretty sure I heard one

[01:22:54.0000] <odinho>
Cool, nice that it'll continue kennyluck!

[01:23:03.0000] <odinho>
Props to you

[01:23:10.0000] <kennyluck>
Noooooooo

[02:07:08.0000] <zcorpan>
kennyluck++

[03:32:32.0000] <jgraham>
Did someone say status markers on bugs?

[03:32:53.0000] <jgraham>
(seems to be broken in Opera though :( )

[03:33:21.0000] <zcorpan>
:(

[03:38:13.0000] <jgraham>
It is broken for other people, right?

[03:38:23.0000] <jgraham>
I mean the whole status thing is missing?

[03:40:30.0000] <zcorpan>
i see status boxes in 12.01

[03:40:44.0000] <jgraham>
Hmm I have -next

[03:41:24.0000] <jgraham>
But it worked on the spec I had loaded before

[03:46:15.0000] <Ms2ger>
jgraham, there's no way to change the spec section after the fact, I guess?

[03:46:32.0000] <jgraham>
Ms2ger: It just uses the URL field at the moment

[03:46:38.0000] <jgraham>
So editing that ought to work

[03:46:42.0000] <jgraham>
I didn't try though

[03:46:59.0000] <Ms2ger>
How often does it update?

[03:47:07.0000] <jgraham>
At the moment? Never

[03:47:23.0000] <Ms2ger>
That's not a lot

[03:47:34.0000] <jgraham>
But I will set up a cron job and give Hixie a hook to trigger an update after a bug is posted

[03:49:08.0000] <Ms2ger>
Oh, heh, the bugs filed on #head end up attached to the TOC on the multipage parts

[03:49:13.0000] <zcorpan>
jgraham: this is awesome. thanks

[03:49:47.0000] <Ms2ger>
jgraham++

[03:51:47.0000] <gsnedders>
Why is there no clear documentation of what is stable in ES6 drafts and what is likely to change? >_>

[03:52:51.0000] <scott_gonzalez>
Hixie MikeSmith: I can read through the <template> discussions again (and my timezone is ET)

[03:53:51.0000] <MikeSmith>
scott_gonzalez: I remember that Ojan at least had specifically responded to you with some rationale about why markup was needed

[03:55:15.0000] <scott_gonzalez>
MikeSmith: Is the main benefit having a native solution for Web Components?

[03:55:27.0000] <MikeSmith>
yes

[03:55:37.0000] <MikeSmith>
I guess that's not clear from the rest of the thread

[03:55:54.0000] <MikeSmith>
but that in fact is what this is needed for

[03:56:15.0000] <MikeSmith>
I don't know that anybody has any other use in mind for it other than that

[03:57:02.0000] <MikeSmith>
I remember an hsivonen question in that thread that indicated he wasn't aware of that either

[03:57:16.0000] <scott_gonzalez>
I guess that seems fine. I'm not sure it's really a big win to have a declarative way to define loops and the such.

[03:57:44.0000] <scott_gonzalez>
Do we expect components that need logic and don't need JS?

[03:58:45.0000] <scott_gonzalez>
I should probably read the Web Components spec again.

[03:58:55.0000] <scott_gonzalez>
I only read it once and it was a while ago.

[04:00:11.0000] <MikeSmith>
scott_gonzalez: I don't think we'd expect components that need logic but don't need JS, no.

[04:00:23.0000] <MikeSmith>
But I'm not expert on those specs either

[04:00:34.0000] <MikeSmith>
dglazkov would be the person to ask

[04:00:47.0000] <MikeSmith>
he's in US/West I think

[04:00:53.0000] <scott_gonzalez>
ok

[04:01:19.0000] <scott_gonzalez>
I'm juts having a hard time thinking about how a component would make use of nested templates and looping without having to do a bunch of logic in JS anyway.

[04:01:33.0000] <scott_gonzalez>
s/juts/just/

[04:01:46.0000] <MikeSmith>
right

[04:02:19.0000] <MikeSmith>
I would think it still need the JS logic too but I could well be wrong about that

[04:02:40.0000] <MikeSmith>
there is no purely declarative way to do this as far as I can see

[04:02:54.0000] <scott_gonzalez>
I have an item on my todo list to convert a jQuery UI widget into a web component.

[04:03:10.0000] <scott_gonzalez>
But I won't be able to work on that for at least 1-3 weeks.

[04:03:11.0000] <MikeSmith>
that would be a good exercise for sure

[04:03:31.0000] <scott_gonzalez>
We're in crunch time for a release.

[04:03:35.0000] <MikeSmith>
OK

[04:03:58.0000] <MikeSmith>
we should really try to have another face-to-face meeting somewhere early next year to talk about Web Components

[04:04:19.0000] <MikeSmith>
I'm sure we will be having a discussion at the WebApps WG meeting in November

[04:04:38.0000] <MikeSmith>
but that will be in France and I think a lot of people will not be traveling to it

[04:05:07.0000] <scott_gonzalez>
Do you know where the next one after that will be?

[04:06:30.0000] <MikeSmith>
scott_gonzalez: if we do in fact end up doing it, most likely in Mountain View or nearby I guess

[04:07:01.0000] <scott_gonzalez>
I can probably attend that.

[04:07:44.0000] <MikeSmith>
it will just be a matter of seeing if there's enough interest and then somebody taking responsibility for planning it

[04:08:06.0000] <MikeSmith>
I guess it's probably something we'll talk about at the WebApps meeting in November

[04:08:55.0000] <scott_gonzalez>
ok

[04:11:40.0000] <deane>
MikeSmith: Hi, what mailing list do bugs from this component go to? https://www.w3.org/Bugs/Public/enter_bug.cgi?product=Validator%20%28Nu%29

[04:11:56.0000] <MikeSmith>
hey deane

[04:12:00.0000] <MikeSmith>
no mailing list, maybe

[04:12:14.0000] <MikeSmith>
wait no, www-validator-cvs⊙wo

[04:12:24.0000] <MikeSmith>
see the QA Contact field

[04:12:40.0000] <deane>
I see

[04:12:59.0000] <MikeSmith>
deane: they also go to mike+validator⊙wo

[04:13:09.0000] <MikeSmith>
so you can just set a watch on that address if you want

[04:13:17.0000] <deane>
I see

[04:14:20.0000] <deane>
so there will be double ups with .nu's bugzilla then? Two bugzillas for one validator

[04:15:12.0000] <deane>
How come it doesn't have the text field and file upload functionality?

[04:15:58.0000] <MikeSmith>
it does have those

[04:16:09.0000] <MikeSmith>
and yeah I guess there could be redundant bugs

[04:16:18.0000] <MikeSmith>
but those a easy to deal with

[04:17:19.0000] <MikeSmith>
deane: the select menu at http://validator.w3.org/nu/ has "Address", "File Upload", and "Text Field"

[04:17:31.0000] <MikeSmith>
it requires that you have JS enabled

[04:18:33.0000] <deane>
Yeah, just noticed that :)

[04:20:01.0000] <deane>
I wish hsivonen had a mailing list for .nu's bugzilla. I think it's only you and him that get the notifications.

[04:30:53.0000] <zcorpan>
deane: add hsivonen to your watch list. http://bugzilla.validator.nu/userprefs.cgi?tab=email

[04:31:58.0000] <deane>
zcorpan: thanks, I'll set that up.

[04:50:23.0000] <zcorpan>
jgraham: would it be hard to put the bug summary in the link title=""?

[04:52:26.0000] <jgraham>
zcorpan: I was thinking that too

[04:52:39.0000] <jgraham>
Easy on my end at least

[04:53:28.0000] <jgraham>
It would require a different wire format and stuff, but nothing that would be difficult to change I think

[05:05:42.0000] <zcorpan>
would be nice for sure

[05:14:11.0000] <jgraham>
I am thinking we should be able to do something similar for tests (maybe a link per section to tests for that section, genertated from whatever manifest data people have added) and that the other stuff that's currently in the status markers isn't that useful

[05:14:48.0000] <jgraham>
Would be nice if the implementation status could be outsourced to caniuse.com

[05:15:42.0000] <zcorpan>
yeah

[05:16:05.0000] <zcorpan>
and finally, it would be nice to have all this for other specs, too (and i want a pony) :-)

[05:17:55.0000] <jgraham>
I might fix up some code to scrape which tests apply to each section in the next few days

[05:19:39.0000] <jgraham>
Could map caniuse.com data to section ids (for at least top level sections) and get some implementation status data from there

[05:19:44.0000] <jgraham>
https://github.com/Fyrd/caniuse/blob/master/data.json

[05:38:00.0000] <zcorpan>
jgraham: so what happens when a bug is no longer open, does it leave the section box lying around or does it remove it if there's no other data in it?

[05:38:41.0000] <jgraham>
zcorpan: The box will just end up in the state it would have been in if there had never been a bug

[05:38:48.0000] <jgraham>
But Hixie did that whole end

[05:39:01.0000] <zcorpan>
ok

[05:39:07.0000] <jgraham>
My role in the enterprise is just scraper of data

[05:39:34.0000] <jgraham>
(for small values of "scrape" since it is XML and CSV rather than HTML)

[05:40:45.0000] <odinho>
jgraham: That would be ace, in fact. Using caniuse api.

[05:40:53.0000] <odinho>
s/api/datha

[06:56:44.0000] <smaug____>
no rniwa

[06:56:54.0000] <smaug____>
I wonder in which time zone he is in?

[06:57:14.0000] <Ms2ger>
jp?

[07:06:33.0000] <jgraham>
Indeed, I was under the impression he works in the Googleplex in MV

[07:07:12.0000] <smaug____>
Ms2ger: hey, another thing. Since anne is apparently away, do you happen to know how stable prepend()/append() etc are in DOM4

[07:07:21.0000] <smaug____>
after/before will change sure

[07:07:29.0000] <jarek>
is there somewhere a JSON version of this table? http://www.w3.org/TR/SVG/attindex.html

[07:07:53.0000] <Ms2ger>
I haven't seen feedback on it for ages, so I assume either stable or ignored :)

[07:08:07.0000] <jgraham>
Not ignored

[07:08:30.0000] <Ms2ger>
Must be stable, then

[07:08:54.0000] <Ms2ger>
jgraham, you're denying to comment on whether or not you're implementing? :)

[07:09:23.0000] <jgraham>
Ms2ger: No comment on whether or not I am commenting :p

[07:09:30.0000] <Ms2ger>
Dammit :)

[07:10:26.0000] <smaug____>
somewhere between ignored and stable then..

[07:51:38.0000] <gsnedders>
Ms2ger: Oh come on, you know we're implementing it, along with everything else in HTML5/DOM4/CSS3/XSLT2/$otherSpecHere, because how else would we do it first!?

[07:52:22.0000] <gsnedders>
We implement stuff within days of it getting specced!

[07:52:28.0000] <gsnedders>
We just have rather long times to market. :P

[07:52:41.0000] <gsnedders>
s/./ at times./

[08:33:02.0000] <Hixie>
jgraham: yeah adding titles seems like a great thing to do

[08:33:19.0000] <Hixie>
jgraham: i can set something up when i get to the office

[08:33:35.0000] <Hixie>
would be a slightly bigger pain on my end but nothing unmanageable

[08:34:19.0000] <Hixie>
jgraham: doing the tests too would be great, that's actually already supported

[08:34:39.0000] <Hixie>
jgraham: you'd just have to plug into the existing API for updating section markers

[08:35:42.0000] <Hixie>
i looked into doing implementation status from caniuse at some point but that was gonna be more than trivial so i didn't bother

[08:35:46.0000] <Hixie>
i'd love to have that automatic too though

[09:51:00.0000] <odinho>
Hixie: What is needed? A mapping from section to the data? Maybe the upstream data could even get that in.

[10:22:38.0000] <Hixie>
odinho: yeah

[10:26:30.0000] <Hixie>
jgraham: yt?

[10:33:33.0000] <Hixie>
jgraham: i've changed the wire format and database

[10:35:13.0000] <smaug____>
still no rniwa

[10:36:03.0000] <Hixie>
jgraham: updated the front-end, too

[10:40:41.0000] <TabAtkins>
smaug____: rniwa works in our SF office.

[10:49:04.0000] <Ms2ger>
I've seen rniwa on the list

[10:52:55.0000] <TabAtkins>
zcorpan: Someone just suggested that inline CAS + parser-inserted elements could do the adjustments synchronously.  I don't immediately see any problems with this - it's just adjusting the set of attributes attached to the element during building, essentially.

[10:55:02.0000] <TabAtkins>
Well, minor problem I suppose - if the inline CAS is late in the document, it'll only apply synchronously to elements *after* it in the stream, I guess.  This might be confusing.

[10:55:50.0000] <TabAtkins>
However, there's no reason at all to put your CAS in late - linked CAS is automatically async, and inlined CAS doesn't need to wait for any elements to load, like JS might.

[11:30:15.0000] <smaug____>
/me wonders how to deal with this webkit limitation "can't implement this and that because that would leak"

[11:30:41.0000] <smaug____>
that affects heavily to APIs

[11:30:48.0000] <smaug____>
and it is very odd limitation

[11:31:21.0000] <smaug____>
rniwa: FYI, I doubt Gecko would implement undomanager per page approach

[11:35:49.0000] <Hixie>
man i hate how you can't 'transition' from max-height:0 to max-height:auto

[11:42:10.0000] <Hixie>
Ms2ger: are there specific urgent bugs you need me to look at?

[11:42:16.0000] <Hixie>
Ms2ger: (if so, mark them "critical")

[11:42:22.0000] <Ms2ger>
Don't think so

[11:42:25.0000] <Hixie>
k

[11:42:56.0000] <Ms2ger>
Actually, you fixed one of them yesterday :)

[11:43:19.0000] <Hixie>
the only bugs i remember fixing yesterday were typos that i was fixing while watching tv :-)

[11:43:30.0000] <Ms2ger>
The Attr bug

[11:43:36.0000] <Hixie>
oh right

[11:43:42.0000] <Hixie>
close enough to a typo

[11:43:47.0000] <Ms2ger>
You should watch more tv, it seems to help you get work done :)

[11:44:12.0000] <Hixie>
heh

[11:44:20.0000] <Hixie>
i've been doing lots of stuff recently

[11:44:26.0000] <Hixie>
rewrote the whoel ruby section :-)

[11:44:30.0000] <Hixie>
that was like days' worth of work

[11:44:43.0000] <rniwa>
smaug____: i'm not suggesting that either.

[11:45:09.0000] <rniwa>
smaug____: i specifically avoided spec'ing how undo inside a text field works

[11:45:28.0000] <rniwa>
smaug____: given that there are different needs from different vendors

[11:45:36.0000] <Ms2ger>
Hixie, well, I don't care about ruby ;)

[11:45:41.0000] <rniwa>
smaug____: we probably need to make undoscope content attribute optional

[11:46:01.0000] <rniwa>
smaug____: alternatively, we can get rid of "undo()" and "redo()" from undo manager API

[11:46:12.0000] <smaug____>
rniwa: optional in which sense?

[11:46:13.0000] <rniwa>
smaug____: and the definition of active undo manager platform dependent

[11:46:21.0000] <rniwa>
smaug____: that some browsers won't support it

[11:46:44.0000] <smaug____>
rniwa: no optional features in APIs

[11:47:02.0000] <rniwa>
smaug____: then, we need to get rid of undo() and redo() from undoManager.

[11:47:12.0000] <rniwa>
smaug____: i mean... i don't have to use the term optional

[11:47:24.0000] <rniwa>
smaug____: i can just make it not do anything on browsers that don't support multiple undo managers per document.

[11:47:41.0000] <rniwa>
smaug____: the thing is... we can have multiple undo managers per document, and that's final.

[11:47:44.0000] <rniwa>
smaug____: there's nothing we can do about it.

[11:47:52.0000] <Hixie>
ok i poked at the status boxes' styles a bit

[11:47:58.0000] <Hixie>
hopefully y'all think they look prettier now

[11:47:59.0000] <smaug____>
we isn't the idea to give web developers to make whatever kind undo handling they want

[11:48:07.0000] <smaug____>
page level or field level

[11:48:17.0000] <rniwa>
smaug____: no.

[11:48:26.0000] <hober>
undo behavior should match the local platform convention

[11:48:40.0000] <rniwa>
smaug____: the idea of undo manager is to let browsers know the existence of undo stack in the page

[11:49:08.0000] <rniwa>
smaug____: if they just wanted to do whatever the heck they want, just add a random entries to undo manager

[11:49:15.0000] <rniwa>
smaug____: and then mantain your own undo manager

[11:49:22.0000] <rniwa>
smaug____: then you can do whatever the hell you want.

[11:49:27.0000] <Hixie>
btw are there any opera people around who have an opinion on <template>?

[11:49:39.0000] <rniwa>
smaug____: and i don't intend stop you from doing that.

[11:50:19.0000] <rniwa>
smaug____: all we're asking is to let us not violate platform conventions and let us make our decision as to what can be implemented and what cannot be implemented in our engine.

[11:50:33.0000] <Hixie>
also i plan to post http://wiki.whatwg.org/wiki/What_you_can_do to alistapart pretty soon so if anyone sees anything wrong with it, please let me know asap

[11:51:00.0000] <rniwa>
smaug____: i'm totally fine and respectful of the fact gecko (and opera) chose to have a separate undo manager per text field

[11:51:05.0000] <smaug____>
rniwa:  yeah, in practice it is "this is hard to implement in webkit, so lets do a dummy API"

[11:51:16.0000] <rniwa>
smaug____: and i don't intend to comprose that either.

[11:51:17.0000] <rniwa>
smaug____: no.

[11:51:21.0000] <Ms2ger>
Hixie, hmm, I don't see bug annotations, am I just missing them?

[11:51:33.0000] <rniwa>
smaug____: it's not just hard. it's impossible.

[11:51:53.0000] <smaug____>
rniwa: what I'm even more worried that since webkit can't handle certain kinds of APIs, that will lead to worse APIs also elsewhere

[11:52:04.0000] <Hixie>
Ms2ger: they're all gone except in the #introduction box for now

[11:52:09.0000] <smaug____>
rniwa: it is hard, not impossible

[11:52:12.0000] <Hixie>
Ms2ger: i'm waiting for jgraham to update his end to send bug titles

[11:52:16.0000] <rniwa>
smaug____: it is impossible in practice

[11:52:22.0000] <smaug____>
rniwa: Gecko had similar problems

[11:52:34.0000] <rniwa>
smaug____: we're not going to adopt Gecko's approach

[11:52:35.0000] <smaug____>
but then we implemented cycle collector

[11:52:38.0000] <rniwa>
smaug____: nor are we willing to fix that problem.

[11:52:43.0000] <smaug____>
other options are also possible

[11:52:43.0000] <Ms2ger>
Hixie, oh, right

[11:52:47.0000] <smaug____>
like to gc for everything

[11:52:50.0000] <rniwa>
smaug____: but we're not going to do that.

[11:52:55.0000] <rniwa>
smaug____: we have discussed this.

[11:52:59.0000] <smaug____>
that is your choice

[11:53:00.0000] <rniwa>
smaug____: and that's our conclusion.

[11:53:02.0000] <rniwa>
smaug____: yes

[11:53:14.0000] <rniwa>
smaug____: and i'm asking you to respect that.

[11:53:43.0000] <rniwa>
smaug____: the matter of fact is that we're going to veto the spec anyway if we kept the spec as is.

[11:53:55.0000] <smaug____>
rniwa: well, I'm worried that web APIs will be less than optimal because one major browser engine can't handle certain basic things

[11:54:08.0000] <rniwa>
smaug____: i don't consider this as "basic things"

[11:54:09.0000] <smaug____>
rniwa: at least would be great to have some documentation what all webkit can't handle

[11:54:25.0000] <smaug____>
so that we could try to avoid such constructs in APIs

[11:54:43.0000] <rniwa>
smaug____: maybe.

[11:55:02.0000] <rniwa>
smaug____: it was my fault. i should have chekced our how our object model works earlier

[11:55:17.0000] <smaug____>
rniwa: if you have a GCed language like JS, and you design APIs for it, it is quite natural to expect that the underlying implementation can handle cycles

[11:55:39.0000] <rniwa>
smaug____: we can handle cycles in javascript objects

[11:55:46.0000] <Hixie>
fwiw, when there's a disagreement like this, at the end of the day, if you can't come to agreement, the way to solve it is to implement what you think is best and then ship it early enough that your implementation gets more traction than the other

[11:56:17.0000] <Hixie>
and then the "losing" side gets to implement the other API or lose web compat

[11:56:38.0000] <rniwa>
Hixie: are you talking to us?

[11:56:43.0000] <Hixie>
yes :-)

[11:56:47.0000] <rniwa>
Hixie: yeah.

[11:56:55.0000] <rniwa>
Hixie: my current plan is create a custom build of chromium with this feature

[11:56:58.0000] <smaug____>
Hixie: well, so far webkit devs have made pretty clear they won't accept any certain kinds of APIs, which cause cycles in C++

[11:57:00.0000] <rniwa>
Hixie: and let develpoers play with it.

[11:57:37.0000] <Hixie>
smaug____: if you just implement that kind of API and get it widely adopted, you'll force the webkit devs to implement such an API anyway, and then your problem is solved :-)

[11:57:47.0000] <Hixie>
(presumably at great cost to the webkit project)

[11:58:20.0000] <smaug____>
(I don't know why it is so great cost when all the other engines have the solution)

[11:58:30.0000] <Hixie>
(disclaimer: i have no idea what exactly we're talking about here in terms of the undomanager api, so i have no opinion on the actual issue)

[11:58:36.0000] <rniwa>
Hixie: i mean... we're not going to implement it anyway.

[11:58:45.0000] <rniwa>
Hixie: it's not a matter of whether we work hard or not.

[11:58:46.0000] <Hixie>
rniwa: if all the other browsers implement it, you'd end up implementing it

[11:58:51.0000] <rniwa>
Hixie: not really.

[11:58:59.0000] <rniwa>
Hixie: we can choose not to implement it :)

[11:59:06.0000] <Hixie>
you can chose to lose lots of market share :-)

[11:59:08.0000] <rniwa>
Hixie: just like WebGL isn't implemented by IE

[11:59:20.0000] <Hixie>
yeah, and we'll see how long they manage to hold out

[11:59:32.0000] <smaug____>
Hixie: as far as I've understood webkit devs say they won't implement certain kinds of APIs. It is not quite clear to me what all cause problems for them

[11:59:52.0000] <smaug____>
apparently even MutationObserver is hard (and leaky atm)

[12:00:18.0000] <rniwa>
smaug____: the problem is that our JS engine uses garbage collection but all C++ objects are ref-counted

[12:00:31.0000] <smaug____>
yes

[12:00:37.0000] <smaug____>
Gecko works the same way

[12:00:52.0000] <smaug____>
JS is GCed and C++ refcounted

[12:01:08.0000] <smaug____>
(but we have cycle collector to kill the cycles )

[12:02:09.0000] <rniwa>
smaug____: https://docs.google.com/document/d/1uYHpq7u5Sslj54UgzXjA7pYR53XjidpBcrCa-neOGQs/edit?pli=1

[12:02:18.0000] <rniwa>
smaug____: this explains how nodes are managed in webkit

[12:03:08.0000] <Hixie>
rniwa: for the record, "we can't implement that" is a bit of a weak argument given that we're talking about software. i mean, you can implement it. not wanting to is a different matter.

[12:03:28.0000] <Hixie>
rniwa: (again, i've no knowledge of the precise issue here, i'm just talking in general terms)

[12:03:34.0000] <rniwa>
Hixie: well, if we were to implement this, we might as well as write our engine from scratch

[12:03:51.0000] <Hixie>
mozilla did do that once

[12:04:15.0000] <rniwa>
Hixie: and we're not going to do that.

[12:04:27.0000] <rniwa>
Hixie: so it's impossible in practice

[12:04:43.0000] <smaug____>
cycle collector was added to gc+refcounted engine

[12:04:49.0000] <smaug____>
it was a bit painful yes

[12:04:59.0000] <smaug____>
but it is not impossible in practice

[12:05:13.0000] <Hixie>
"we don't want to do that" is a different argument than "it's impossible". i'm just saying you'll get much better reactions from other vendors if you just say "we don't want to" than if you claim that something is impossible, especially if they have done it.

[12:05:14.0000] <rniwa>
smaug____: the problem is that cycle collector will regress the performance will introduce a significant complexity to the code base.

[12:05:36.0000] <rniwa>
Hixie: sure. i guess it's a wording issue :/

[12:07:18.0000] <Hixie>
(from a competitive point of view, it seems gecko would be well positioned to introduce a widely-used api that forced you to take that hit to remain relevant, so it seems wise for webkit to get the alternative API used widely before gecko does theirs :-) )

[12:07:44.0000] <rniwa>
Hixie: that's why we're already implementing it :)

[12:08:34.0000] <smaug____>
/me needs to design some awesome new API  which is all about cycles :)

[12:09:17.0000] <Hixie>
rniwa: then you run the opposite risk, namely pissing off other vendors because you're forcing what they consider a bad api down their throat... it seems you're screwed either way :-)

[12:09:37.0000] <rniwa>
Hixie: it's okay :)

[12:09:45.0000] <rniwa>
Hixie: i'm used to pissing other ppl off

[12:09:50.0000] <rniwa>
Hixie: that's my way life :P

[12:09:54.0000] <rniwa>
way of*

[12:13:18.0000] <rniwa>
Hixie: at the end of the day, there are things we don't do. like we'll never implement XBL2.0

[12:14:44.0000] <Hixie>
if firefox and IE both used it and Amazon, CNN, and eBay all depended on it, you would.

[12:14:56.0000] <Hixie>
s/used/implemented/

[12:14:59.0000] <rniwa>
Hixie: maybe.

[12:15:03.0000] <Hixie>
come now

[12:15:06.0000] <Hixie>
there's no "maybe" there

[12:15:12.0000] <rniwa>
Hixie: or maybe we'll just lose the market share because we decide not to implement it.

[12:15:57.0000] <Hixie>
uh huh

[12:16:15.0000] <Hixie>
hober: aren't bugs supposed to get some boilerplate when they're closed? (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16793)

[12:30:45.0000] <cabanier>
jacobolus: I got some info from the photoshop engineers.

[12:31:58.0000] <cabanier>
jacobolus: exclusion doesn't give intuitive or useful results in Lab mode. The blending modes are meant to be visually pleasing, not mathematically correct

[12:32:30.0000] <hober>
Hixie: yes

[12:32:38.0000] <hober>
Hixie: looks like jay doesn't know that

[12:32:43.0000] <hober>
Hixie: i will bug him

[12:32:54.0000] <cabanier>
jacobolus:  people who want to emulate the math behind exclusion can do it themselves

[12:53:24.0000] <Hixie>
hober: k

[13:19:49.0000] <jacobolus>
cabanier: the reason that's unsatisfying as answers is (1) exclusion mode never gives visually pleasing results, in any color space; it's purely for tricky special effects or as an intermediate step in something else, and really only useful to someone who knows what's going on, and the “usefulness” is identical in RGB or Lab, (2) it's not possible to "emulate" the result in any obvious way, except by through a bunch

[13:19:49.0000] <jacobolus>
 of explicit manual steps, or by doing some math in an external tool, or similar. There's no way to do it that is anywhere near so useful when you're actively working in photoshop and exclusion mode would enable some truly awesome possibilities

[13:21:21.0000] <jacobolus>
also (3) no one but an expert is using Lab mode anyhow, because none of the tools are very well optimized for it. This is yet another limitation that makes it less pleasant than RGB, and this time an entirely arbitrary one

[13:23:08.0000] <jacobolus>
but anyway, oh well. I came to accept that it wouldn't happen several years ago. not worth worrying too much about

[14:35:45.0000] <Hixie>
who's css3 ui's editor currently?

[14:35:51.0000] <Hixie>
or selectors, i guess

[14:35:55.0000] <Hixie>
let me rephrase

[14:36:07.0000] <Hixie>
who is in charge of the :read-only and :read-write selectors?

[14:37:34.0000] <Hixie>
no tab, no tantek, no ms2ger

[14:37:52.0000] <Hixie>
/me checks his calendar to make sure he's not missing some event or something

[14:42:31.0000] <hober>
tantek's editing css3 ui, and fantasai is editing selectors 4

[14:47:56.0000] <Hixie>
k

[14:53:39.0000] <Hixie>
heycam: i got some [AllowAny] DOMString arguments, do I just drop [AllowAny] ?

[14:54:20.0000] <heycam>
Hixie, yes DOMString arguments should always be preferred when an argument doesn't match the other overload types

[14:54:41.0000] <Hixie>
ok

[15:03:28.0000] <Hixie>
heycam: so there's no difference between an attribute that's "attribute any foo;" and one where it's "attribute (DOMString | SpecialFoo) foo;" except that in the latter case things like coaxing to DOMString if the input is null or { valueOf: ... } etc are handled by Web IDL?

[15:04:18.0000] <Hixie>
er, "or", not "|"

[15:06:05.0000] <Hixie>
heycam: and if so, is there a way for me to define that i want an attribute that on setting always coaxes the input to DOMString but on getting could return "any"?

[15:26:48.0000] <heycam>
Hixie, for the first question, yes that's right; for the second, unfortunately there isn't

[15:27:04.0000] <Hixie>
k

[15:27:14.0000] <Hixie>
is there an equivalent for [AllowAny] for "long" ?

[15:27:41.0000] <heycam>
no, but if there is no DOMString argument overloaded with it it will select the long

[15:27:42.0000] <Hixie>
i have a method where UAs treat integers one way, and everything else 0

[15:28:11.0000] <Hixie>
do i have to make it take any?

[15:28:38.0000] <heycam>
I don't think so, let me check though

[15:28:50.0000] <Hixie>
(HTMLOptionCollection.remove())

[15:28:52.0000] <heycam>
so you want f("abc") and f(node) to be like f(0)?

[15:29:02.0000] <Hixie>
yeah

[15:29:05.0000] <Hixie>
and f(NaN)

[15:29:17.0000] <heycam>
ok so I *think* it might be like that currently but I'll just confirm]

[15:29:25.0000] <Hixie>
and f(0.5)

[15:29:31.0000] <heycam>
/me always forgets what the latest state of all the overload resolution stuff is

[15:29:42.0000] <Hixie>
but f(60.5) treated as f(60) apparently

[15:29:59.0000] <heycam>
always truncating?

[15:30:06.0000] <Hixie>
i've tested four numbers so far

[15:30:09.0000] <Hixie>
they all seemed to truncate

[15:30:11.0000] <Hixie>
but what do i know

[15:30:20.0000] <heycam>
ha

[15:30:49.0000] <Hixie>
seems like it truncates for all the numbers i care about

[15:31:03.0000] <Hixie>
-0.1 and -0.9 => 0

[15:31:10.0000] <heycam>
ok so that should be right, if you don't have an exact match then it'll prefer a DOMString argument, and if there's no DOMString argument it'll prefer a primitive argument

[15:31:17.0000] <heycam>
so it's then just down to the normal rules for converting to long

[15:31:22.0000] <Hixie>
ah cool

[15:31:25.0000] <heycam>
if they match what you need..

[15:31:35.0000] <Hixie>
so if i have a method that takes a long it'll never throw TYPE_MISMATCH?

[15:31:40.0000] <Hixie>
or whatever hte exception is

[15:31:50.0000] <heycam>
(TypeError)

[15:31:54.0000] <heycam>
right

[15:32:03.0000] <Hixie>
how convenient

[15:32:04.0000] <Hixie>
ok

[15:32:04.0000] <Hixie>
cool

[15:32:05.0000] <Hixie>
thanks

[15:32:16.0000] <heycam>
cool

[15:35:31.0000] <Hixie>
it astounds me how good a job we are doing of speccing the web platform these days, compared to where we were 13 years ago

[15:35:51.0000] <Hixie>
(web idl being a huge part of that)

[15:36:04.0000] <heycam>
hooray

[15:44:30.0000] <Yuhong>
http://www.w3.org/2001/tag/2011/12/evolution/

[15:44:35.0000] <Yuhong>
http://www.w3.org/wiki/Evolution

[15:44:39.0000] <Yuhong>
I wonder what happened

[15:47:12.0000] <Hixie>
hober: your copy/paste resolutions are cute :-P

[15:54:32.0000] <Hixie>
hober: is there any documentation anywhere that tracks which revisions the w3c spec has adopted and which it hasn't?

[15:59:18.0000] <Hixie>
hober: also, is there something somewhere i can use to keep track of the decisions that were applied? I'm trying to update the list of ways the specs are forked

[16:11:03.0000] <Yuhong>
DirectX vs OpenGL again, now against CSS Shaders: http://codeflow.org/entries/2012/aug/22/css-shaders-w3c-microsoft-and-broken-standards/

[16:12:39.0000] <jamesr>
the rant is strong with this one

[16:13:26.0000] <zewt>
yeah i closed the window as soon as i saw every other word bolded with some randomly in weird colors

[16:15:22.0000] <zewt>
(the distracting animations and mugshot didn't help on the "worth reading" scale, either)

[16:26:31.0000] <Yuhong>
https://news.ycombinator.com/item?id=4422022

[16:38:10.0000] <Yuhong>
jamesr: But considering it is MS fragmenting the web yet again, I am not surprised.

[16:38:41.0000] <jamesr>
i think the article is really misinformed


2012-08-24
[19:37:02.0000] <roc>
in what way?

[19:42:46.0000] <jamesr>
roc, was that to me?

[19:43:23.0000] <roc>
yes

[19:44:15.0000] <jamesr>
it's supposing that microsoft wants to introduce their own shading language. i suspect they simply want to avoid the IPR obligations that requiring glsl would imply

[19:44:23.0000] <jamesr>
i really doubt they want anything at all

[19:46:13.0000] <roc>
IIRC the IPR argument was not raised the first time they objected to specifying GLSL

[19:46:21.0000] <roc>
I could be wrong.

[19:47:22.0000] <jamesr>
just because they didn't say it doesn't mean they weren't thinking it

[19:48:14.0000] <roc>
I suppose you could strike "They prefer their own shading language they call IESL.", but that doesn't affect the thrust of the rant, which is that it's absurd to standardize "CSS Shaders" without a standard common shading language

[19:48:33.0000] <jamesr>
i don't think they even want to standardize css shaders

[19:49:01.0000] <roc>
if not, they're not saying it for some reason

[19:49:57.0000] <jamesr>
it doesn't really impact them at all if someone goes off and creates a standard unless it triggers IPR for them

[19:50:29.0000] <roc>
sure it does, because they'll be expected to support it sooner or later.

[19:51:16.0000] <roc>
it's kinda hard to avoid the conclusion that they don't like GLSL for the same reason they don't like WebGL. The reason for *that* is a bit more speculative, but maybe not much more :-)

[19:52:21.0000] <jamesr>
it doesn't really matter if they object on IPR grounds, which they definitely do

[19:52:32.0000] <jamesr>
so making further conspiracy theories just seems like a waste of time

[19:54:46.0000] <othermaciej>
Microsoft seems to be asking for GLSL to be a MAY-level rather than SHOULD-level requirement

[19:54:50.0000] <othermaciej>
at least in that original email

[19:55:53.0000] <othermaciej>
I think anything less than a MUST does not trigger w3c IPR commitments

[20:14:04.0000] <othermaciej>
hmm, Sylvain seems to think SHOULD and RECOMMENDED mean different things in RFC2119 language

[20:18:40.0000] <othermaciej>
but I guess it does not matter since both appear to trigger the patent policy - optional features are covered as long as they are normative

[20:19:19.0000] <othermaciej>
however, the patent policy excludes "technology developed elsewhere and merely incorporated by reference in the body of the Recommendation"

[20:19:58.0000] <roc>
I would have expected GLSL to be excluded by that

[20:20:42.0000] <othermaciej>
so I think the IPR claim is doubtful

[20:21:05.0000] <othermaciej>
it is hard to assess the non-IPR objections, the thread has a poor signal-to-noise ratio

[20:21:16.0000] <jamesr>
yeah the thread is crap

[20:21:31.0000] <jamesr>
othermaciej, do you think he's not assessing it in terms of IPR and he's wrong, or that's not his concern?

[20:21:57.0000] <jamesr>
sorry too many negatives. do you think his assessment of the RFC2119 triggers is wrong, or that's not what he is bothered by?

[20:22:10.0000] <othermaciej>
his claims about IPR are:

[20:22:28.0000] <othermaciej>
(1) RECOMMENDED is an RFC2119 keyword that "is not just an optional should"

[20:22:52.0000] <othermaciej>
(2) therefore the W3C patent policy likely applies to IPR on GLSL

[20:23:05.0000] <othermaciej>
these statements are false or misleading for the following reasons:

[20:23:47.0000] <othermaciej>
(A) RECOMMENDED and SHOULD are synonyms in RFC2119, so they have no difference in normative effect (I am puzzled how he could miss this while quoting the RFC_

[20:24:28.0000] <othermaciej>
(B) The W3C patent policy covers optional features so long as they are normatively specified, so the fact that recommended is in fact optional does not matter

[20:25:13.0000] <othermaciej>
C) however the w3c patent policy excludes technologies developed elsewhere and incorporated by reference, so it likely would not apply to GLSL in any case

[20:25:40.0000] <crocket>
What do I use instead of <frame> with HTML5 web pages?

[20:25:44.0000] <crocket>
<frame> is obsolete.

[20:25:55.0000] <jamesr>
<iframe> typically

[20:26:01.0000] <othermaciej>
that depends on what you are trying to do

[20:26:26.0000] <othermaciej>
if you want an independently browsable area that really needs to hold separate pages, <iframe>

[20:26:38.0000] <crocket>
hmm....

[20:26:42.0000] <othermaciej>
if you just want your page to have separate areas that scroll independently, CSS overflow: scroll

[20:26:43.0000] <crocket>
I know what <iframe> is.

[20:27:04.0000] <othermaciej>
(that is, make it all one page and use overflow: scroll on the scroll containers)

[20:27:17.0000] <crocket>
othermaciej, Can you show me an example of how CSS overflow property works?

[20:27:41.0000] <othermaciej>
crocket: not offhand but if you google or bing it I am sure you will find some good tutorials

[20:28:48.0000] <crocket>
othermaciej, ok

[20:28:56.0000] <crocket>
kennyluck_, Who killed you?

[20:33:27.0000] <jamesr>
othermaciej, is that something you can ask the w3c people to convince the microsoft lawyers of? your logic sounds reasonable, but IANAL and if they don't feel comfy here they are quite capable of blocking this for a long time

[20:33:38.0000] <jamesr>
i doubt replying on that thread could do much good, especially at this point

[20:34:08.0000] <othermaciej>
I am hesitant to wade into the topic since it is a flame-splosion right now

[23:18:51.0000] <MikeSmith>
oh cool an interface index

[23:20:43.0000] <MikeSmith>
non-element interfaces

[23:20:46.0000] <MikeSmith>
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#all-interfaces

[23:44:11.0000] <MikeSmith>
http://lists.webkit.org/pipermail/webkit-dev/2012-August/022049.html is interesting

[23:44:32.0000] <MikeSmith>
Apple going all out on CSS Regions it seems

[00:59:11.0000] <odinho>
Aiai, I think I think pipermail should always force linebreaks if there is none. Always have to monkeypatch it in Dragonfly to be able to read pipermail archives :P

[01:01:22.0000] <Philip`>
/me just does ctrl+F11 (fit to width) in Opera

[01:04:11.0000] <odinho>
Philip`: That should teach me to learn all of my browsers hidden features. :S  Thanks! :D That's a super cool feature.

[01:07:35.0000] <deane>
/me is disappointed that opera has discontinued it's irc chat feature.

[01:13:37.0000] <jgraham>
Bug annotations now have titles

[01:40:59.0000] <Ms2ger>
jgraham++

[01:51:55.0000] <zcorpan>
nice!

[01:52:30.0000] <zcorpan>
Hixie: it's a bit annoying that the bug links move when you hover. can the section link be moved to the bottom of the box, or so?

[02:01:53.0000] <jgraham>
Argh, there was a WHATWG email and a gecko bug and maybe a spec bug about the interaction between loading and session history, and now I can't find any of them

[02:03:55.0000] <zcorpan>
Hixie: http://whatwg.org/specs/ doesn't list these specs: http://www.w3.org/community/whatwg/

[02:11:02.0000] <zcorpan>
Hixie: http://wiki.whatwg.org/wiki/Test_cases might be better if we point people to http://www.w3.org/html/wg/wiki/Testing

[02:14:52.0000] <zcorpan>
Hixie: "and in five to ten years you'll finally be able to do it!" - it doesn't necessarily have to take 5+ years

[02:15:35.0000] <jgraham>
zcorpan: You could just edit some of these pages you know :)

[04:11:41.0000] <sedovsek>
Just read this tweet:

[04:11:41.0000] <sedovsek>
https://twitter.com/w3c/status/238652019089485824

[04:11:48.0000] <sedovsek>
Twitter, Inc. (@TwitterEng) joined W3C http://dlvr.it/22l89w

[04:12:02.0000] <sedovsek>
Are there any Twitter employees that already contribute to W3C?

[04:12:12.0000] <kennyluck>
Not I know of.

[04:12:14.0000] <sedovsek>
If so, on which standards/drafts?

[04:12:40.0000] <kennyluck>
Tracking related stuff maybe?

[04:13:13.0000] <sedovsek>
I don't know, but I'm very curious.

[04:14:03.0000] <sedovsek>
Perhaps @TabAtkins has more insights?

[04:15:07.0000] <kennyluck>
sedovsek, if you know their corporate email domain, you can do a search here: http://www.w3.org/Search/Mail/Public/search?keywords=

[04:15:25.0000] <sedovsek>
Thanks.

[04:46:22.0000] <carli2>
hi

[04:46:38.0000] <carli2>
I tried to ask a question in #html, but that was forbidden

[04:47:05.0000] <carli2>
does this channel has to do with that?

[04:47:21.0000] <jgraham>
Have to do with HTML?

[04:47:53.0000] <carli2>
I wanted to ask if/how I can load a static JSON document into a html page

[04:47:58.0000] <jgraham>
Yes; this is mostly people involved with in the development of specs around the web platform

[04:48:03.0000] <carli2>
ah

[04:49:32.0000] <jgraham>
carli2: If you are generating the while thing server-side you can probably do <script type="text/json">/*json data*/</script>

[04:49:52.0000] <jgraham>
If you want to pull in an enternal file, use XHR

[04:50:29.0000] <carli2>
jgraham: but how can I access the JSON object then? the script is executed in the global scope

[04:51:04.0000] <jgraham>
carli2: You can read the content of the script element and use JSON.parse

[04:51:14.0000] <jgraham>
Or whatever the method is called

[04:51:16.0000] <carli2>
ah

[04:58:46.0000] <carli2>
jgraham: I cannot read the content from the <script> element

[04:59:53.0000] <jgraham>
Internal or external script?

[04:59:58.0000] <sedovsek>
There's also a #html5 chann, which might be slightly more appropriate.

[05:00:06.0000] <jgraham>
An internal script should be readable with .textContent

[05:00:07.0000] <sedovsek>
an*

[05:00:08.0000] <carli2>
jgraham: should work for both, SO and non-SO

[05:00:31.0000] <jgraham>
Oh, well if you are trying to read data cross-origin things are harder

[05:00:41.0000] <jgraham>
Then you probably want to use CORS + XHR

[08:14:43.0000] <jgraham>
So, is there an event I can get in the top level browsing context when I navigate the joint session history of a browsing context with nested browsing contexts in such a way that it is one of the child browsing contexts that chnages its document

[08:14:47.0000] <jgraham>
?

[08:15:24.0000] <jgraham>
i.e. I have a parent document A with an iframe in itially containing B. I navigate the iframe to C and then do history.go(-1)

[08:15:43.0000] <jgraham>
I want an event that will fire when I am back at B in the iframe

[08:37:43.0000] <Hixie>
jgraham: i got method not allowed?

[08:42:03.0000] <jgraham>
Hixie: I forgot to restart the server. Try again?

[08:48:10.0000] <Hixie>
jgraham: awesome

[08:48:30.0000] <Hixie>
ok i put it at the bottom of file-bug.cgi

[08:48:40.0000] <Hixie>
hopefully it doesn't break anything :-)

[08:48:44.0000] <Hixie>
this is awesome stuff

[08:48:50.0000] <Hixie>
really glad we did this

[08:48:55.0000] <jgraham>
Me too :)

[08:49:26.0000] <Hixie>
i also like my new styling for the boxes :-)

[08:50:08.0000] <jgraham>
Indeed, but see zcorpan's comment; having the bug link move on hover is annoying

[08:50:19.0000] <Hixie>
moved it already

[08:50:51.0000] <jgraham>
Oh, I didn't reload

[08:50:56.0000] <jgraham>
It takes a while ;)

[08:51:34.0000] <Hixie>
ok, afk for a bit

[08:56:06.0000] <jgraham>
Hixie: New style is much better, thanks

[09:52:57.0000] <TabAtkins>
All right, time to lose a few hours of productivity and get this new workstation set up.

[10:36:10.0000] <dglazkov>
good morning, Whatwg!

[10:36:22.0000] <dglazkov>
TabAtkins: vroom, vroom

[12:10:21.0000] <Hixie>
is there anywhere i can make a note of some tests that should be added to the html test suite?

[12:10:42.0000] <Hixie>
(i want to note that we need to test that legacycaller isn't supported for all interfaces that have a getter)

[12:13:05.0000] <Ms2ger>
Hixie, you can file a bug in the HTMLWG/testsuite product

[12:13:09.0000] <Ms2ger>
I might even see it there

[12:13:39.0000] <Hixie>
ah, cool, that's for actual bugs, not just infrastructure?

[12:13:55.0000] <Ms2ger>
Yep

[12:15:02.0000] <Hixie>
cool

[12:15:16.0000] <Hixie>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18681

[12:15:21.0000] <Hixie>
that clear enough?

[12:15:46.0000] <Ms2ger>
Clear enough for me

[12:15:59.0000] <Hixie>
oooooh, would it help if i added something to the live dom viewer that automatically filed a bug in that component with the current contents?

[12:16:14.0000] <Ms2ger>
Hmm, would be nice

[12:16:44.0000] <Ms2ger>
Now all we need is a script to automatically translate it to an automated test :)

[12:22:05.0000] <Hixie>
Ms2ger: default assignee, or should i assign to someone in particular?

[12:22:26.0000] <Ms2ger>
Default is fine

[12:23:37.0000] <Hixie>
anyone i should put in default cc?

[12:26:11.0000] <Ms2ger>
Feel free to put me, but I don't think it's going to make me do anything sooner :)

[12:26:28.0000] <Hixie>
entirely up to you

[12:27:01.0000] <Ms2ger>
Don't, then, I get heaps of bugmail already :)

[12:27:04.0000] <Hixie>
i'd put myself in to monitor for abuse, but i send all w3c bugmail to trash :-)

[12:30:22.0000] <jamesr>
s/bugmail //

[12:31:15.0000] <Hixie>
i still monitor public-html in case anyone raises a bug i have to fix

[12:31:25.0000] <Hixie>
hasn't happened in recent years, but we never know...

[12:57:34.0000] <TabAtkins_>
Yesssssss.  Now to banish my old self.

[13:07:23.0000] <rubys>
hixie: re: "hober: is there any documentation anywhere that tracks which revisions the w3c spec has adopted and which it hasn't? "

[13:07:53.0000] <rubys>
this is a small part of that (which bugs are still open that have clones):

[13:07:54.0000] <rubys>
http://intertwingly.net/tmp/clones.html

[13:08:17.0000] <rubys>
if I can build reports that are helpful, let me know

[13:52:49.0000] <hober>
Hixie: you can follow along at https://github.com/w3c/html/commits/master/

[13:53:20.0000] <hober>
(with regard to which revisions from the whatwg spec have been applied to the w3c spec)

[14:22:45.0000] <Hixie>
hober: that tells me which have been applied, but not which have not :-)

[14:24:59.0000] <hober>
true

[14:27:05.0000] <GPHemsley>
Hixie: Any idea why the JSURL development stalled?

[14:27:23.0000] <Hixie>
what is JSURL?

[14:27:41.0000] <GPHemsley>
The JavaScript URL standard

[14:31:06.0000] <GPHemsley>
(mentioned in the recent r7265)

[14:33:33.0000] <Hixie>
oh the javascript: spec?

[14:33:35.0000] <Hixie>
no iea

[14:33:37.0000] <Hixie>
idea


2012-08-25
[18:10:13.0000] <smaug____>
Hixie: enum BinaryType { "blob", "dom-BinaryType-arraybuffer">arraybuffer" };

[18:10:17.0000] <smaug____>
doesn't look right

[18:10:28.0000] <smaug____>
should be enum BinaryType { "blob", "arraybuffer" }; ?

[02:57:05.0000] <jgraham>
Ms2ger: Oh you had already replied and more usefully. Oops

[07:49:45.0000] <rubys>
hixie: "git log master..feature/whatwg" <=  shows what whatwg revisions have not been applied to the w3c spec

[09:34:19.0000] <Ms2ger>
/me wonders if it's defined anywhere that window is the global object

[09:49:12.0000] <Hixie>
Ms2ger: html defines things close to that, if not that itself

[09:49:30.0000] <Hixie>
Ms2ger: search for global object, global environment, and the dfn for "script!"

[09:49:35.0000] <Hixie>
s/!//

[09:50:02.0000] <Ms2ger>
I was looking around there, I may just have missed the exact line :)

[09:50:03.0000] <zewt>
"script!" makes me think ruby D:

[11:31:40.0000] <annevk>
MikeSmith: seems it's all in order now, http://isoc.nl/activ/2012-Masterclass-HTML5-MichaelSmith.htm

[11:37:51.0000] <Ms2ger>
s/technologieen/technologie�n/

[11:42:36.0000] <annevk>
Ms2ger continues to amaze

[11:42:52.0000] <Ms2ger>
Why thank you

[11:43:45.0000] <Ms2ger>
Those dots are important, dammit :)

[11:48:44.0000] <annevk>
Watching Trollhunter, all that Norwegian is awesome :)

[11:56:35.0000] <annevk>
Note to self: board some of those ferries

[11:58:24.0000] <Ms2ger>
annevk, if you get hunted down by a troll and are never heard of again... That would not be good for us :)

[11:58:57.0000] <annevk>
Good point, they do say it's a true story right at the start

[12:06:00.0000] <zewt>
nothing is quite as impressive in a website as a credit card entry form that says next to it: "do not include spaces"

[12:06:12.0000] <zewt>
removing spaces is a technically challenging task

[12:09:29.0000] <annevk>
ah yeah, same with postal codes here in NL

[12:10:02.0000] <annevk>
sometimes you have to include the space, sometimes not, pretty terrible UI in general, optimized for databases rather than users

[12:10:24.0000] <Ms2ger>
Who invented 4 digits + 2 letters anyway

[12:13:43.0000] <annevk>
http://nl.wikipedia.org/wiki/Postcodes_in_Nederland has some information on what it signifies, but not much on history


2012-08-26
[23:41:07.0000] <annevk>
teehee, twitter profile pages are /{username} again

[00:10:12.0000] <Ms2ger>
/me loves how Hixie consistently used dom-cva-checkValidatity

[00:17:42.0000] <Hixie>
i use copy and paste a _lot_ :-)

[00:17:58.0000] <Hixie>
and emacs' dabbrev-expand

[00:18:06.0000] <Hixie>
(i even have that bound to my foot pedal)

[00:22:35.0000] <Ms2ger>
/me notes: "Essential to spec editing: a foot pedal"

[02:54:46.0000] <annevk>
can someone please check http://annevankesteren.nl/about for weird mistakes?

[02:54:53.0000] <annevk>
(also not so weird mistakes)

[03:20:16.0000] <deane>
annevk: Hi, try validating it

[03:50:32.0000] <annevk>
hmm, what's 'Unsupported character encoding name: charset=utf-8. Will sniff.'

[03:51:05.0000] <annevk>
sounds like a bug in the validator

[03:51:34.0000] <annevk>
MikeSmith: is that because you recently changed the regular expression the validator uses for encodings?

[03:51:40.0000] <annevk>
hsivonen: ^^

[03:54:26.0000] <annevk>
MikeSmith: hsivonen: I suspect it might be because I have no space between ";" and "charset", which is perfectly legal, but might be a case you have not considered

[03:54:48.0000] <deane>
annevk: yeah, try it at validator.w3.org and it works

[03:55:12.0000] <deane>
which would be an older revision of validator.nu

[03:57:47.0000] <annevk>
nice that I also manage to break validators

[04:07:09.0000] <annevk>
Ms2ger: has Microsoft forked DOM Parsing & Serlialization yet?

[04:07:37.0000] <Ms2ger>
Haven't seen anything yet

[04:12:10.0000] <annevk>
With standards it seems you really need to take a break that lasts longer than a couple of months before anything substantive has happened

[04:14:28.0000] <Ms2ger>
I'd rather you didn't :)

[05:25:34.0000] <MikeSmith>
MikeSmith: I actually a replaced that regular expression with a state machine

[05:25:49.0000] <MikeSmith>
annevk: ↑

[05:26:22.0000] <MikeSmith>
so yeah I probably forgot to deal with the no-space case there

[05:26:43.0000] <MikeSmith>
annevk: this is for the Content-Type header, right?

[05:28:47.0000] <MikeSmith>
annevk: ah actually it's working at http://validator.w3.org/nu/?doc=http%3A%2F%2Fannevankesteren.nl%2F

[05:30:15.0000] <MikeSmith>
which has the latest code, with that regexp replaced by the new parser

[05:30:35.0000] <MikeSmith>
so I think the error at validator.nu is because Henri has not pulled that new code yet

[05:35:29.0000] <annevk>
interesting

[05:35:36.0000] <annevk>
because I think I used to validate on validator.nu

[05:35:48.0000] <annevk>
thanks MikeSmith

[05:36:15.0000] <MikeSmith>
I'll take a look again the old regexp and see

[05:37:53.0000] <MikeSmith>
weird

[05:37:55.0000] <MikeSmith>
"^\\s*charset\\s*=\\s*(?:\"([^\"\\s]+)\")|([^\"\\s]+)\\s*$"

[05:37:59.0000] <MikeSmith>
is what is was

[05:38:19.0000] <MikeSmith>
so it should be working even if Henri's still running the old code

[05:40:05.0000] <MikeSmith>
and the case in the new code for it looks like this: https://gist.github.com/3478622

[05:40:40.0000] <MikeSmith>
so it should work either way as far as I tell

[05:49:26.0000] <annevk>
weird that it doesn't, then

[06:08:56.0000] <smaug____>
annevk: ping

[06:09:10.0000] <smaug____>
(welcome back)

[06:09:41.0000] <annevk>
hey smaug____

[06:09:55.0000] <smaug____>
annevk: I wonder the status of element.prepend() etc new methods

[06:10:13.0000] <smaug____>
there was some discussion to change before and after

[06:10:19.0000] <annevk>
I think they're all good, though I just read a thread between episodes about before/after

[06:10:20.0000] <annevk>
indeed

[06:11:07.0000] <annevk>
not that I agree with everything Alex writes, but the library argument http://infrequently.org/2012/08/inadmissible-arguments/ did not seem particularly compelling

[06:11:38.0000] <annevk>
the whole reason we added these was to have shorter names

[06:11:54.0000] <annevk>
(and ES6-style API)

[06:11:58.0000] <smaug____>
hmm, /me doesn't actually understand what all can be passed to those methods

[06:12:02.0000] <smaug____>
and in which way

[06:12:17.0000] <smaug____>
I guess element.prepend("asdfo", someotherelement, "bar");

[06:12:53.0000] <annevk>
that's like inserting a DocumentFragment consisting of a text, element, and a text node

[06:13:21.0000] <smaug____>
it is not, because the argument is something else

[06:13:30.0000] <smaug____>
I mean, is it an array

[06:13:46.0000] <smaug____>
or is it a list of separate parameters

[06:13:50.0000] <smaug____>
/me reads webidl..

[06:13:57.0000] <annevk>
it's not an array

[06:14:43.0000] <smaug____>
yup

[06:16:06.0000] <annevk>
and by stable I mean that everyone agreed to the design when we added it, but I don't think anyone gave the actual text a careful reading

[06:16:58.0000] <annevk>
smaug____: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-method-macro takes care of converting stuff to a DocumentFragment

[06:17:00.0000] <smaug____>
I wonder who strings are handled

[06:17:09.0000] <annevk>
smaug____: you don't actually have to do that of course in your implementation

[06:17:10.0000] <smaug____>
how

[06:17:25.0000] <smaug____>
I mean, is toString() called

[06:17:58.0000] <annevk>
smaug____: WebIDL handles that

[06:18:07.0000] <smaug____>
I hope so

[06:18:17.0000] <annevk>
me too :)

[06:18:25.0000] <annevk>
but I'm pretty sure it does

[06:18:49.0000] <smaug____>
/me downloads D4 and WebIDL for offline reading... boarding in any minute

[06:19:41.0000] <annevk>
hehe

[07:48:08.0000] <zewt>
annevk: i think i strongly dislike the before/after names too; it sounds like a query, like "search for a node with this CSS selector starting with this element and moving backward", not like a mutator

[07:49:56.0000] <zewt>
fwiw, while i definitely agree that a lot of the old DOM names are way too long (getElementById needs to die), i think the insertBefore name is just fine

[07:57:52.0000] <zewt>
currently writing code to manipulate XML using minidom and it's making me a sad person

[08:48:36.0000] <jgraham>
zewt: Why would you do that?

[08:49:54.0000] <jgraham>
(also the problem I have with insertBefore is that it's on the wrong node, so I can never remember the order of the arguments parent.insertBefore(target, reference) is crazy compared to reference.addBefore(target)

[08:49:58.0000] <jgraham>
)

[08:51:43.0000] <jgraham>
(although I guess it could be target.addBefore(reference). So I kind of underminded my own point there. But at least you only need two nood references around, not 3)

[08:51:47.0000] <jgraham>
*node

[08:52:23.0000] <jgraham>
*undermined

[08:52:34.0000] <zewt>
(jgraham: because all XML implementations suck and from the ones I've used recently it has the right set of bugs)

[08:54:00.0000] <jgraham>
zewt: Wow you must have a weird set of requirements

[08:54:11.0000] <zewt>
well recently i've used it, ET and lxml

[08:54:45.0000] <zewt>
iirc lxml (or at least the ones installed in OSX by default, I think newer ones improve it) wouldn't pass through doctypes, don't recall the issue I hit with ET off-hand

[08:56:07.0000] <jgraham>
I pretty much exclusively use lxml, but happily almost never have to care about doctypes

[08:56:30.0000] <zewt>
i don't personally care, but I'm editing external data in-place so I don't want things messed with that don't have to be

[08:56:41.0000] <jgraham>
I see

[08:56:59.0000] <Ms2ger>
/me just uses JS

[09:13:41.0000] <zewt>
am I the only person who can never remember if it's "startswith" or "beginswith"?

[09:14:44.0000] <Ms2ger>
startswith

[09:19:00.0000] <jgraham>
zewt: Well that's one I have never had difficulty with

[09:19:11.0000] <Philip`>
/me finds it much easier to remember "$s =~ /^foo/" than "s.startswith('foo')"

[09:19:49.0000] <Ms2ger>
/me murders Philip` 

[09:20:31.0000] <jgraham>
Philip` was strange

[09:21:55.0000] <zewt>
"starts" and "begins" are in the same hash bucket in my mind; something like "isprefixed" would have been more distinct, if a little uglier


2012-08-27
[18:13:48.0000] <Hixie>
how is -moz-box-sizing still not unprefixed

[18:13:51.0000] <Hixie>
it's been over a decade now

[22:45:20.0000] <zcorpan>
wonder if we can introduce a way for authors to opt out of https://www.w3.org/Bugs/Public/show_bug.cgi?id=11960 (something like "use strict")

[22:48:24.0000] <zewt>
heh, i've started writing pages with fewer and fewer ids ... not really for that reason, but it does help reduce it

[22:52:00.0000] <zewt>
heh microsoft saying "pages break" and the only example anyone's come up with is microsoft.com? really?

[22:55:15.0000] <zcorpan>
yep

[22:55:51.0000] <zcorpan>
but i'm sure there are more that break, they're just hard to find (especially since they likely use browser sniffing and barewords)

[23:10:16.0000] <zcorpan>
what's up with http://html5.org/tools/web-apps-tracker?from=7277&to=7278 ?

[23:13:44.0000] <zcorpan>
Hixie: btw, having links to bug in commit message and link to diff in bug comment was quite helpful. is it much extra work?

[23:16:06.0000] <MikeSmith>
zcorpan: weird. http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2012/006432.html has the diff

[23:16:20.0000] <zcorpan>
oh, nevermind, i see you included that in later commits

[23:16:23.0000] <zcorpan>
MikeSmith: yeah

[23:33:46.0000] <annevk>
Ms2ger: next time you just remove yourself from the CC list, please don't add a comment

[23:33:54.0000] <annevk>
Ms2ger: now I get email, otherwise I wouldn't

[00:18:56.0000] <annevk>
whatever came out of the lazy Blob thread?

[00:18:59.0000] <annevk>
nothing?

[00:20:35.0000] <Ms2ger>
Sounds about right

[00:25:50.0000] <zcorpan>
annevk: you expect things to *happen*? are you new here? :-)

[00:32:00.0000] <annevk>
zcorpan: yeah, what is this place anyway?

[00:32:19.0000] <jgraham>
This is #lazylayabouts

[00:32:30.0000] <jgraham>
But we changed the name for PR reasons

[00:36:21.0000] <annevk>
ooh

[00:36:28.0000] <annevk>
I'm no longer in WebApps or WebAppSec

[00:36:42.0000] <jgraham>
I am very tempted to respond to dglazkov's packaging thread with "show me the use cases". It's not that I doubt that there are use cases for web sites having dependencies, but it is very hard to tell what the actual requirements are without having been to his f2f meetings

[00:36:43.0000] <annevk>
and no longer have W3C Member access

[00:36:52.0000] <annevk>
more freedom, yay

[00:37:09.0000] <annevk>
no W3C Member access, but still in Chairs

[00:37:11.0000] <annevk>
I wonder how that works

[00:37:27.0000] <annevk>
hahaha

[00:37:32.0000] <annevk>
I can no longer access the Chairs guide

[00:38:14.0000] <annevk>
I'm in Chairs, but not in the Notifications WG

[00:38:27.0000] <annevk>
weird

[00:45:52.0000] <smaug____>
annevk: Join Mozilla and become a member again :)

[01:36:27.0000] <annevk>
I'm still in the Forms Task Force

[01:36:31.0000] <annevk>
anyone remember that one?

[01:36:52.0000] <Ms2ger>
No :)

[01:37:31.0000] <jgraham>
annevk: So, which is more useful, the Forms Task Force or the Chairs list?

[01:37:57.0000] <annevk>
Chairs I guess, I still get the supposedly Member-only email

[01:38:45.0000] <Ms2ger>
Oh, look, https://svgwg.org/svg2-draft/

[01:40:36.0000] <annevk>
https://svgwg.org/svg2-draft/changes.html is the interesting bit

[01:41:31.0000] <annevk>
"Added the ‘maskType’ attribute to the ‘mask’ element." yay more HTML parser changes upcoming

[01:41:47.0000] <Ms2ger>
Oh look, a reference to DOM4

[01:42:01.0000] <annevk>
and why not name it "type"?

[01:42:03.0000] <Ms2ger>
As well as DOM2EVENTS, DOM2STYLE and DOM2VIEWS

[01:42:38.0000] <annevk>
why not Zoidberg?

[01:43:34.0000] <annevk>
overall though it seems like many small steps in the right direction

[01:46:53.0000] <annevk>
nobody updated DOM4 in the last two months

[01:49:18.0000] <annevk>
MikeSmith: so say I still want to try this W3C thing for now, how do I apply for Invited Expert status for WebApps/WebAppSec/Notifications?

[01:49:35.0000] <annevk>
MikeSmith: I assumed that would happen automatically when I changed affiliation, but apparently it does not

[01:53:09.0000] <annevk>
ah, found https://www.w3.org/2002/09/wbs/1/ieapp/

[01:53:44.0000] <zcorpan>
yay for svg to embrace webidl and dom4

[01:55:45.0000] <annevk>
hmm

[01:55:50.0000] <annevk>
maybe I don't want to be an Invited Expert

[01:56:03.0000] <annevk>
"The Invited Expert agrees to refrain from creating derivative works that include the Invited Expert's contributions when those derivative works are likely to cause confusion about the status of the W3C work or create risks of non-interoperability with a W3C Recommendation. «Branching» is one example of a non-permissible derivative work."

[01:56:08.0000] <annevk>
from http://www.w3.org/Consortium/Legal/2007/06-invited-expert.html

[01:57:07.0000] <annevk>
seems kind of contradictory to giving the W3C a nonexclusive copyright

[02:08:38.0000] <zcorpan>
annevk: sent an email about maskType

[02:09:30.0000] <annevk>
and I submitted aforementioned form by indicating I do not agree with the terms

[02:09:35.0000] <annevk>
I wonder what happens

[02:17:18.0000] <odinho>
I don't understand what that thing is supposed to prohibit.

[02:17:29.0000] <odinho>
Evil invited experts? And what about evil companies/members then?

[02:18:15.0000] <Ms2ger>
odinho, people publishing specs outside the W3C and undermining the W3C's authority

[02:18:20.0000] <Ms2ger>
Basically, WHATWG

[02:18:44.0000] <odinho>
Ms2ger: But why only place that on invited experts?

[02:19:19.0000] <odinho>
I mean, it's a stupid thing, but it has squared stupidity when it's not consistent.

[02:19:37.0000] <jgraham>
Ms2ger: Also, say, ePub

[02:19:48.0000] <Ms2ger>
Hah, ePub

[02:20:31.0000] <annevk>
Ms2ger, you also Ms2ger on github?

[02:20:33.0000] <jgraham>
(I mean if http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-xhtml-additions isn't a "derivative work" I don't know what is)

[02:21:58.0000] <jgraham>
(and clearly by implementing additions, you risk non-interoperability with HTML UAs that fail to implement those additions)

[02:22:27.0000] <jgraham>
(plus the next section is called "deviations")

[02:23:05.0000] <Ms2ger>
annevk, yes

[02:23:17.0000] <Ms2ger>
Though I hate it

[02:23:47.0000] <jgraham>
Ms2ger: You don't like git? Who knew?

[02:24:11.0000] <Ms2ger>
"Deviations" reminds me of http://en.wikipedia.org/wiki/The_Chrysalids

[02:24:14.0000] <annevk>
Ms2ger: I read you can access it through hg-git, so you should be okay

[02:28:02.0000] <annevk>
jgraham: you did this kind of thing before right?

[02:28:25.0000] <annevk>
jgraham: say I create a github repository, can I then put a hg repository in it without much hassle?

[02:28:31.0000] <annevk>
jgraham: or is there some other way to go about it

[02:29:19.0000] <jgraham>
annevk: doublec knows all. Im particular http://www.bluishcoder.co.nz/2011/02/10/git-conversion-of-mozilla-central.html

[02:31:06.0000] <annevk>
interesting

[02:31:20.0000] <annevk>
I don't necessarily care about keeping things in sync afterwards

[02:31:52.0000] <annevk>
but I guess I should install that hg-git thing

[02:32:34.0000] <jgraham>
Yeah it is still probably the best way of doing the one-time import

[02:32:47.0000] <jgraham>
Or export depending on your point of view

[02:34:31.0000] <annevk>
of course, first need to update MacPorts

[02:41:17.0000] <jgraham>
OK, why do gecko/webkit fail to run the last two tests in http://hoppipolla.co.uk/tests/history/001.html (popups needed)

[02:42:21.0000] <jgraham>
(yes the test is kind of very ugly)

[02:46:58.0000] <annevk>
almost catched up on 100 or so threads, nothing much interesting, apart from a few minor bugs in DOM

[02:47:23.0000] <annevk>
a lot of agenda bullshit

[03:20:12.0000] <annevk>
apparently my 512x512 rendering of the WHATWG logo downscales poorly as seen on https://github.com/whatwg

[03:20:19.0000] <annevk>
if anyone has a better solution, please let me know

[03:21:30.0000] <Ms2ger>
Do they take SVG images?

[03:22:23.0000] <jgraham>
annevk: Surely if you downscale it yourself in photogimp you can get acceptable results?

[03:23:23.0000] <annevk>
Ms2ger: nope, goes via gravatar

[03:24:17.0000] <annevk>
jgraham: the problem is they scale it themselves to various resolutions

[03:26:02.0000] <jgraham>
annevk: So wait, we are spending time worrying about the tiny fraction of people with retina displays, and they won't even let you upload a 64x64 image to use at 64x64?

[03:26:29.0000] <jgraham>
er 140x140

[03:26:29.0000] <annevk>
uhuh

[03:26:42.0000] <annevk>
the web is a funny place

[03:26:50.0000] <annevk>
or hell, but that depends on your pov

[03:26:53.0000] <jgraham>
Wait

[03:27:03.0000] <jgraham>
It is github's fault (I think?)

[03:27:25.0000] <jgraham>
They are showing a 140x140 image at 48x48

[03:27:39.0000] <annevk>
that sounds like their fault

[03:27:58.0000] <ruby_on_tails>
how to fallback to the default font till the custom font used in a canvas loads ?

[03:27:59.0000] <annevk>
maybe also why it renders somewhat better depending on which browser you use

[03:28:19.0000] <ruby_on_tails>
i suddenly have a slow internet and the font takes too long to load and other things start animating on the canvas

[03:28:33.0000] <ruby_on_tails>
and no text shows up till the font loads which fails a lot of times on slow net

[03:28:37.0000] <ruby_on_tails>
thats bad

[03:29:00.0000] <annevk>
ruby_on_tails: can't you set a fallback font?

[03:29:08.0000] <ruby_on_tails>
annevk: how ?

[03:29:15.0000] <ruby_on_tails>
ctx.font = "20px arial"

[03:29:24.0000] <ruby_on_tails>
can i use "20px arial, verdana" ?

[03:29:34.0000] <ruby_on_tails>
let me try

[03:30:17.0000] <ruby_on_tails>
ctx.font = "50px bebas, arial"; doesnt work

[03:30:50.0000] <annevk>
per the spec that's a browser bug

[03:31:06.0000] <ruby_on_tails>
whats the solution for now ?

[03:31:18.0000] <annevk>
file a bug on the relevant browser

[03:31:45.0000] <annevk>
and you can check if something was drawn and if not, reset the font and do it again

[03:31:47.0000] <annevk>
I guess

[03:36:30.0000] <ruby_on_tails>
but is that code supposed to work ?

[03:36:35.0000] <ruby_on_tails>
ctx.font = "50px bebas, arial";

[03:36:44.0000] <annevk>
yeah

[03:37:29.0000] <ruby_on_tails>
i cant see such usage in any SO answer or doc reference

[03:38:31.0000] <annevk>
tutorials never cover the whole spec

[03:39:37.0000] <ruby_on_tails>
hmm

[03:40:12.0000] <ruby_on_tails>
why doesnt window.onload wait for fonts ?

[03:40:19.0000] <ruby_on_tails>
it should wait for fonts like images i guess

[03:40:28.0000] <ruby_on_tails>
maybe i am wrong

[03:43:21.0000] <jgraham>
Sigh

[03:43:46.0000] <jgraham>
So browsers don't seem to fire pageshow events from document.open

[03:44:06.0000] <jgraham>
Any idea if this is a compat. need?

[03:57:40.0000] <zcorpan>
downscaling a big image sounds like the right thing to do if you care about retina displays (in this case the image is small enough to not bother with multiple versions)

[03:57:53.0000] <zcorpan>
only opera's rendering looks bad (i filed a bug)

[03:58:30.0000] <zcorpan>
or well, the *right* thing to do in this case would be to use svg

[03:58:41.0000] <jgraham>
Downscaling an image by a non integer ratio sounds like a stupid thing to do

[04:00:12.0000] <zcorpan>
if only the 140x140 version was uploaded to gravatar and you want to display it as 48x48, it has to be downscaled *somewhere*

[04:00:58.0000] <jgraham>
zcorpan: annevk said he had a 512x512 version

[04:01:11.0000] <zcorpan>
oh

[04:01:41.0000] <zcorpan>
well then there's something stupid going on indeed

[04:01:48.0000] <jgraham>
(still not a good ratio of course, but downscaling that to 140 and then to 48 is crazy)

[04:02:29.0000] <annevk>
and if you want perfect icons, you need several of them I'm told

[04:02:43.0000] <annevk>
relying on scaling algorithms is not a good idea per the icon crowd

[04:05:09.0000] <Ms2ger>
http://i.qkme.me/3qnjb3.jpg

[07:35:42.0000] <zewt>
i wonder who would name a child "RGraph.net"

[07:36:10.0000] <jgraham>
There was a guy at Opera named his children C APL and Ruby

[07:36:12.0000] <zewt>
can never understand what's going on the the heads of people who post to mailing lists with a company name

[07:49:40.0000] <karlcow>
zewt: this maybe http://infofranpro.wdfiles.com/local--files/20100624-brand-identity/Brain3d.jpg

[08:07:34.0000] <filipe>
alguem conhece um bom material para quem esta come�ando em html5?

[08:09:26.0000] <jgraham>
filipe: Maybe http://html5doctor.com/resources/ will help you

[08:22:42.0000] <GPHemsley>
Is there a preferred media type for WAVE files? 'audio/vnd.wave' is the one in the RFC, but 'audio/wav' seems to be commonly used.

[09:10:26.0000] <dglazkov>
good morning, Whatwg!

[09:12:03.0000] <deane>
dglazkov: Good morning.

[10:28:33.0000] <Hixie>
is http://philip.html5.org/tests/canvas/suite/tests/ the most up to date / canonical test suite for canvas?

[10:28:41.0000] <Ms2ger>
No

[10:28:49.0000] <Ms2ger>
http://www.w3c-test.org/html/tests/submission/PhilipTaylor/canvas/

[10:30:05.0000] <Hixie>
ah k thanks

[10:30:15.0000] <Hixie>
Philip`: could be good to update your copy with a link to the more canonical copy :-)

[10:30:26.0000] <Hixie>
not that i've done that with any of my css tests

[10:30:27.0000] <Hixie>
but you know

[10:30:29.0000] <Ms2ger>
I've been telling him

[10:30:37.0000] <Ms2ger>
Also that he needs to fix all the bugs :)

[10:35:48.0000] <Hixie>
annevk: http://html5.org/tools/web-apps-tracker?from=7277&to=7278 ?

[10:36:30.0000] <Ms2ger>
Looks empty

[10:36:40.0000] <Hixie>
zcorpan: Re the bug #s, I still include them if doing so is easy. I'm more likely to omit them if e.g. I've already left the bug and moved on to other things by the time I get around to committing.

[10:37:13.0000] <Hixie>
zcorpan: (I used to have to go out of my way to get the bug #s before because the Process required that I describe the change in the bug and the diff was the easiest way to do that)

[10:37:34.0000] <Hixie>
zcorpan: (and so I just had my script post the diff to the bug)

[10:50:56.0000] <Philip`>
/me is aware that he needs to do many things :-(

[10:51:21.0000] <Hixie>
join the club

[10:54:57.0000] <Philip`>
The difference is that you do at least some of many things, whereas I tend to do nothing

[10:55:16.0000] <Hixie>
surely you do _some_thing

[10:56:04.0000] <Philip`>
None of the HTML-related things, at least

[10:56:36.0000] <Hixie>
ah, well, there you go

[10:56:44.0000] <Hixie>
i don't do the non-html-related things :-)

[11:14:17.0000] <jgraham>
/me wonders what Philip` does do

[11:14:57.0000] <Ms2ger>
Gazing at the skies, I assume

[11:15:08.0000] <Hixie>
i added a confirm() prompt to the "bug" link on the live dom viewer, hopefully that will be enough

[11:15:15.0000] <Hixie>
(there were 4-6 bogus bugs filed over the weekend)

[11:15:35.0000] <Ms2ger>
I'm glad I opted out of the cc, then :)

[11:15:41.0000] <jgraham>
Maybe http://krijnhoetmer.nl/irc-logs/whatwg/20090318#l-47 is still accurate

[11:17:44.0000] <Hixie>
if it gets too bad i'll just make the link redirect to a prefilled bug submission page

[11:17:49.0000] <Hixie>
that way you have to have an account

[11:26:08.0000] <Philip`>
jgraham: Nowadays, mostly a job

[11:26:56.0000] <Philip`>
/me doesn't think he's played TF2 for at least a year, except for this afternoon

[11:29:00.0000] <Hixie>
anyone got any Content-Language tests?

[11:29:07.0000] <Hixie>
<meta> pragma Content-Language

[11:29:22.0000] <Hixie>
nevermind, i found mine

[11:32:43.0000] <Ms2ger>
Maybe Julian has some

[12:10:44.0000] <bencc>
are there plans to add CORS to web workers?

[12:12:30.0000] <Hixie>
bencc: to do what?

[12:13:15.0000] <bencc>
Hixie: to load a worker url from a different domain

[12:13:33.0000] <Hixie>
CORS wouldn't be a sane way to do that

[12:13:47.0000] <Hixie>
there's two possible use cases that i see here:

[12:13:55.0000] <Hixie>
1) running a same-origin worker loading script from a remote oritin

[12:13:55.0000] <bencc>
new Worker(someOtherUrl)

[12:14:06.0000] <Hixie>
2) running a worker on another origin

[12:14:22.0000] <Hixie>
1) is possible today using importScripts() or whatever the method is called

[12:14:25.0000] <bencc>
I think I'm talking about 2)

[12:14:42.0000] <Hixie>
yeah, i plan to spec 2) in due course

[12:14:51.0000] <Hixie>
(it wouldn't use CORS)

[12:15:15.0000] <bencc>
I don't really need CORS just to use a worker from a different domain

[12:15:36.0000] <bencc>
can I use an inline worker with importScritpts?

[12:16:31.0000] <Hixie>
inline?

[12:16:39.0000] <bencc>
I'm trying to use https://raw.github.com/mozilla/pdf.js/gh-pages/build/pdf.js

[12:16:57.0000] <bencc>
the script loads a worker which uses the same script

[12:17:11.0000] <Hixie>
scripts can import scripts cross-origin iirc, yes

[12:17:12.0000] <bencc>
but it doesn't work if the pdf.js script is hosted on a different domain

[12:17:18.0000] <Hixie>
just like <script>

[12:17:21.0000] <Hixie>
it's just new Worker() that can't

[12:17:43.0000] <Hixie>
because new Worker() is intended to run the scipts in their origin, and i haven't specced how that'll work yet (it's a security thing)

[12:18:21.0000] <bencc>
what's the difference between new Worker(different domain)

[12:18:28.0000] <bencc>
and import a script inside the worker?

[12:18:37.0000] <bencc>
why the former is a security issue?

[12:19:38.0000] <Hixie>
the current difference is that hte former doesn't do anything and the latter imports the script

[12:19:59.0000] <bencc>
I mean, why is the former a security issue?

[12:20:14.0000] <Hixie>
the future difference will be that the former runs the script in the security context of the remote origin, and it's a security thing because we need to ensure the script opts in to running stuff in its origin, because otherwise you could do all kinds of crazy stuff

[12:21:13.0000] <Hixie>
it'll probably involve an HTTP header similar to CORS (but not CORS, because CORS would also let you read the data, which is a different thing altogether)

[12:21:37.0000] <bencc>
so to make pdf.js work, I just need to create a worker that all it does is importScripts('path/to/pdf.js') ?

[12:22:02.0000] <Hixie>
yeah. you can even create a worker with the URL "data:text/javascript,importScripts('path/to/pdf.js')"

[12:22:08.0000] <Hixie>
per spec, anyway

[12:22:13.0000] <Hixie>
dunno how many browsers support that yet

[12:22:47.0000] <bencc>
I'll check that. thanks

[12:32:20.0000] <ojan>
Hixie: http://html5.org/tools/web-apps-tracker?from=7277&to=7278 how did you come to the conclusion that this is quirks only in webkit?

[12:32:45.0000] <ojan>
Hixie: what i see in local testing is that we always report the computed style as content-box, but we treat it as border-box, quirks or standards

[12:32:46.0000] <Hixie>
testing? :-)

[12:32:57.0000] <Hixie>
let me find the tests again

[12:33:00.0000] <bencc>
Hixie: looks good

[12:33:14.0000] <ojan>
Hixie: thx, just want to make sure there's nothing i'm missing before i start filing webkit bugs

[12:33:16.0000] <bencc>
Hixie: I'm able to use bb = new BlobBuilder();

[12:33:29.0000] <bencc>
bb.append("importScripts('/path/to/file')")

[12:34:40.0000] <bencc>
Hixie: is there a difference between: new Blob(["..."]) and using BlobBuilder ?

[12:34:51.0000] <Hixie>
i know nothing of blobs

[12:35:17.0000] <Ms2ger>
bencc, no

[12:35:33.0000] <Ms2ger>
bencc, except that I'm about to remove BlobBuilder support from Gecko

[12:36:22.0000] <bencc>
Ms2ger: new Blob() has prefix on some browsers?

[12:36:29.0000] <Ms2ger>
No

[12:36:58.0000] <bencc>
cool

[12:37:01.0000] <Hixie>
ojan: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1621 http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1622

[12:37:22.0000] <Ms2ger>
Hixie, did you file a bug for the tests? :):

[12:37:42.0000] <Hixie>
ojan: oh, i misintepreted the testcase

[12:37:56.0000] <bencc>
Ms2ger: is there a safe way to check if Blob can be used?

[12:38:07.0000] <Hixie>
ojan: the bug is that webkit applies it to display:table in quirks mode

[12:38:15.0000] <Hixie>
Ms2ger: which?

[12:38:30.0000] <Ms2ger>
"Those"

[12:38:31.0000] <Hixie>
Ms2ger: content-language or box-sizing-on-table?

[12:38:41.0000] <Ms2ger>
What's content-language, and should I care? :)

[12:39:02.0000] <Hixie>
content-language is the tests i was just dealing with and i just checked in a diff that mentions them, so i thought that might be what you were referring to :-)

[12:39:09.0000] <Hixie>
i haven

[12:39:12.0000] <Hixie>
't filed any

[12:39:16.0000] <Hixie>
bugs on testcases

[12:39:28.0000] <Hixie>
be my guest :-)

[12:39:41.0000] <ojan>
Hixie: the difference i see between webkit and gecko is only in the second case of a table that is display:block

[12:40:14.0000] <Hixie>
ojan: oh dude, i'm just not paying enough attention with this test

[12:40:19.0000] <ojan>
Hixie: lol

[12:40:27.0000] <ojan>
Hixie: the gecko behavior seems wrong to me...

[12:40:39.0000] <Ms2ger>
Clearly Gecko must be right ;)

[12:40:52.0000] <ojan>
Hixie: as in...if we can get away with it, a display:block table should default to content-box

[12:41:08.0000] <Ms2ger>
Ugh

[12:41:09.0000] <ojan>
Hixie: where webkit only border-boxes display:block tables in quirks mode

[12:41:11.0000] <Hixie>
ojan: in webkit, the two tests differ in quirks vs non-quirks

[12:41:14.0000] <ojan>
i don't feel strongly about this

[12:41:37.0000] <ojan>
i suppose making all tables border-box is simpler to spec

[12:41:39.0000] <Hixie>
ojan: mozilla doesn't differ in quirks vs non-quirks

[12:41:46.0000] <ojan>
i'll file a bug to make webkit do that

[12:41:52.0000] <Ms2ger>
Making it depend on the display seems sucky

[12:41:54.0000] <Hixie>
ojan: and no quirkiness is a win

[12:41:59.0000] <ojan>
yeah

[12:42:03.0000] <Hixie>
ojan: it should just be a line in the CSS style sheet

[12:42:05.0000] <ojan>
i agree with both of you :)

[12:42:26.0000] <Hixie>
ojan: i don't understand what webkit is doing, looks like it has both the line in the style sheet and some extra crazy for <table>'s renderer

[12:42:30.0000] <ojan>
it's lame that webkit does this with under the hood magic instead of just changing the computed style

[12:42:45.0000] <ojan>
Hixie: i don't think there's a line in the style sheet

[12:42:53.0000] <Hixie>
why does it affect display:block table then?

[12:43:09.0000] <Hixie>
(but only in quirks mode)

[12:43:13.0000] <Ms2ger>
The HTML5 editors sure seem to spend a lot of time triaging

[12:43:27.0000] <ojan>
Hixie: def no line in the style sheet...

[12:43:40.0000] <Hixie>
Ms2ger: ?

[12:43:44.0000] <ojan>
Hixie: meh, we're probably going down the table code by tagname somewhwere or something dumb

[12:43:56.0000] <Ms2ger>
Hixie, not you, the irrelevant ones ;)

[12:43:56.0000] <Hixie>
Ms2ger: over the weekend?

[12:44:26.0000] <Hixie>
Ms2ger: i'm not an html5 editor, i was just surprised to hear they'd done anything, when i checked in this morning it was unchanged since the 23rd

[12:44:38.0000] <Hixie>
and i haven't seen any bug spam or public-html postage since

[12:45:08.0000] <Hixie>
in fact as far as i can tell, the new editors don't post to public-html even as much as i did

[12:45:18.0000] <Hixie>
in fact i'm pretty sure some of them have _never_ posted

[12:45:53.0000] <Ms2ger>
Seems like they like to add keywords and stuff

[12:46:04.0000] <Ms2ger>
/me has been blissfully ignorant of them

[12:46:22.0000] <Hixie>
oh i don't get keyword bugmail

[12:46:25.0000] <Hixie>
:-)

[12:46:43.0000] <Hixie>
i turned that off after the a11y people started drizzling keywords everywhere

[12:47:38.0000] <Ms2ger>
Summary: "Fix typo", keywords: "a11y-foo a11y-bar"

[12:50:01.0000] <Hixie>
oh, i am getting the bugmail, my deletion script just hasn't noticed yet

[12:50:21.0000] <Hixie>
(not for keywords but for the changes where one of them was closing bugs on the principle that they didn't apply even though they did...)

[12:50:35.0000] <Hixie>
(you'd think the editors would know what sections they had in their spec)

[13:42:36.0000] <ojan>
Hixie: i expect your aware of this, but http://html5.org/r/7278 doesn't seem to have the actual diff

[13:47:17.0000] <TabAtkins>
Hixie: I forget - did we discuss an addition to srcset for providing an intrinsic size for different "art-direction" choices?

[13:47:41.0000] <ojan>
Hixie: if you care https://bugs.webkit.org/show_bug.cgi?id=95123 file the table box-sizing bug

[14:07:00.0000] <annevk>
Hixie: dunno why it's empty

[14:07:05.0000] <annevk>
Hixie: the rest seems to work

[14:07:15.0000] <annevk>
Hixie: is it non-empty if you diff it yourself?

[14:25:06.0000] <GPH-Zeke>
annevk, Hixie, ojan: 7279 is also empty.

[14:25:26.0000] <annevk>
hmm okay

[14:25:29.0000] <GPH-Zeke>
(two in a row)

[14:25:33.0000] <annevk>
so maybe we're running out of space again

[14:25:59.0000] <annevk>
please someone remind me tomorrow

[14:26:11.0000] <GPHemsley>
I assumed there was some part of the spec that wasn't covered by the diff site, but what do I know? :)

[14:29:36.0000] <annevk>
well that's true too

[14:30:03.0000] <annevk>
but the rendering section is part of source

[14:38:46.0000] <Hixie>
TabAtkins: we discussed it in person, but not on the list (and nobody else has brought it up as far as i am aware)

[14:38:55.0000] <Hixie>
ojan: thanks

[14:39:31.0000] <Hixie>
GPHemsley: there are cases like that, but they don't get listed on the tracker page at all because the tracker page only looks at source's logs, iirc

[14:41:42.0000] <TabAtkins>
Okay, I was just wondering about it, since we can ignore the issue if we adopt CAS. ^_^

[14:42:49.0000] <Hixie>
CAS?

[14:42:55.0000] <Hixie>
oh the attribte sheets

[14:47:48.0000] <GPHemsley>
ah, ok

[16:04:36.0000] <zewt>
EVERYONE TALKING ABOUT THE PUSH API DRAFT (whatever that is, sounds like WebSockets) IS IMPRESSIVELY LOUD

[16:05:01.0000] <Hixie>
/me searches for "push api" in his inbox

[16:05:30.0000] <Hixie>
oh you just mean their names

[16:06:06.0000] <Hixie>
oh god, more permission-based apis

[16:06:29.0000] <Hixie>
also, seriously, respec CONSIDERED HARMFUL

[16:06:39.0000] <Hixie>
_everyone_ who uses it ends up screwing up how they write a spec

[16:08:09.0000] <zewt>
is that respec's fault or the fault of the category of people who decide to use respec? :)

[16:08:26.0000] <zewt>
(seems like "people who screw up writing a spec" is a pretty huge category to begin with)

[16:09:21.0000] <Hixie>
if the category of people who write good specs never use respec, that is also an indication of a problem with respec

[16:15:02.0000] <Yuhong>
http://blogs.msdn.com/b/ieinternals/archive/2012/08/28/custom-file-type-formats-renamed-to-zip-on-download-in-internet-explorer-when-application-octet-stream-is-used.aspx

[16:17:19.0000] <zewt>
archived material from the future, MS has *all* the tech

[16:18:16.0000] <TabAtkins>
Looks like the date in the url is generated based on the UTC date, and it's already past midnight there. ^_^

[16:18:22.0000] <zewt>
also "And in the case of ZIP-based formats, the browser's technically right" no, the browser is technically an idiot and that behavior is always 100% wrong

[16:19:29.0000] <Yuhong>
technically right in terms of it being openable by a zip reader.

[16:19:30.0000] <zewt>
i had to work around that idiocy way back when I had my own ZIP-based file format; had to fiddle with the header to keep it from happening (though I thought it was some ancient Safari that had that problem; this was years ago)

[16:20:06.0000] <Yuhong>
It is just not what you generally want to open the file with.

[16:21:25.0000] <zewt>
(also, "file starts with PK"? seriously? it thinks a text file that says "PKZIP rocks" is a ZIP?)

[16:22:26.0000] <Hixie>
zewt: windows thinks a file that starts with a "MZ IS AWESOME" is an executable...

[16:22:26.0000] <zewt>
(the header for ZIP is \x50\x4b\x03\x04)

[16:22:39.0000] <Hixie>
(iirc)

[16:22:59.0000] <Hixie>
(MZ is the DOS .exe header, iirc)

[16:23:11.0000] <Yuhong>
Yep.

[16:28:11.0000] <Yuhong>
http://blogs.msdn.com/b/oldnewthing/archive/2006/01/30/519388.aspx

[16:34:32.0000] <ojan>
TabAtkins: how about s/scope-constrained/scope-filtered ?

[16:34:41.0000] <ojan>
TabAtkins: that's my mental model of it

[16:35:07.0000] <TabAtkins>
That's a better name, yeah.

[16:35:10.0000] <ojan>
TabAtkins: and what browsers would do in practice (match everything and filter out)

[16:35:53.0000] <ojan>
constrained and contained are practically synonyms to me :)

[16:37:12.0000] <ojan>
i'm glad we're solving this problem though...scope-contained >>> scope-filtered/scope-constrained IMO and should be the one we use wherever we're not constrained by back-compat

[16:45:26.0000] <TabAtkins>
Scope-filtered is *useful*, and we should have it, but yeah, scope-contained is much more natural as a default.


2012-08-28
[17:07:40.0000] <Yuhong>
http://logbot.glob.com.au/?c=freenode%23whatwg&s=8+Aug+2012&e=8+Aug+2012#c712060

[17:24:26.0000] <Hixie>
http://lists.w3.org/Archives/Public/www-talk/1992MayJun/0022.html is amusing (i'm sure people have run into it before)

[17:26:12.0000] <Hixie>
http://lists.w3.org/Archives/Public/www-talk/1992JulAug/0017.html too

[17:26:43.0000] <TabAtkins>
Hixie: Your use-case for <font> was "the only element that allowed 'style'".  When people pushed back and you made 'style' global, you killed <font> too.

[17:26:59.0000] <Hixie>
ah yeah

[17:27:03.0000] <Hixie>
that sounds right

[17:27:12.0000] <Hixie>
oh right, <font> was the element that only generators could use or something

[17:27:19.0000] <TabAtkins>
Yeah.

[20:53:35.0000] <Hixie>
anyone got IE handy?

[20:53:38.0000] <Hixie>
any version will do

[21:03:06.0000] <kennyluck>
Hixie, I have IE9 here.

[21:07:38.0000] <Hixie>
what do you get on http://damowmow.com/playground/demos/document-write-and-scripts/002.html ?

[21:07:45.0000] <Hixie>
(and what colour is the text)

[21:09:17.0000] <kennyluck>
Hixie, text: "0 undefined 1" color: black

[21:09:21.0000] <Hixie>
wtf

[21:09:23.0000] <Hixie>
thanks

[21:10:03.0000] <Hixie>
same as firefox 3.6

[21:10:29.0000] <Hixie>
but different than webkit/opera (0 1 2) and different than modern firefox (0 2 2)

[21:10:43.0000] <Hixie>
i wonder if it's not blocking load on the style sheet or something

[21:12:27.0000] <Hixie>
kennyluck: if you're still there, can you try http://damowmow.com/playground/demos/document-write-and-scripts/002-long.html ?

[21:12:30.0000] <Hixie>
it'll dump a bunch of stuff

[21:12:39.0000] <Hixie>
if i could get you to /msg it to me that'd be awesome

[21:14:30.0000] <Hixie>
ohhhh

[21:14:32.0000] <Hixie>
i know what's wrong

[21:14:33.0000] <Hixie>
hang on

[21:15:10.0000] <mthz>
is anyone aware of a copy of the html5lib tokenizer test data that is in alignment with the current spec?

[21:15:24.0000] <mthz>
the current tests are a mess, especially w/r/t error handling for entities

[21:15:35.0000] <Hixie>
kennyluck: can you try http://damowmow.com/playground/demos/document-write-and-scripts/002.html in IE now?

[21:15:51.0000] <Hixie>
kennyluck: (i'd forgotten to take out the console.log() calls which IE and old Firefoxen don't support)

[21:15:51.0000] <kennyluck>
Hixie, sure. 002-long.html gave http://pastebin.mozilla.org/1779848

[21:16:27.0000] <mthz>
or, does anyone which tests the following page even refer to (i.e. where can i get them?) http://wiki.whatwg.org/wiki/Parser_tests

[21:16:53.0000] <Hixie>
mthz: that refers to the tests in the code.google.com repo for html5lib

[21:16:55.0000] <kennyluck>
Hixie, text "2 1 1" color: black

[21:17:01.0000] <Hixie>
kennyluck: !!

[21:17:02.0000] <zewt>
it's pretty (something) that even today you have to jump hoops to see console.log output on ios

[21:17:09.0000] <Hixie>
kennyluck: (you sure it's black and not dark blue?)

[21:17:23.0000] <Hixie>
kennyluck: "2 1 1" is typical IE behaviour. complete nonsense. :-P

[21:17:37.0000] <kennyluck>
Hixie, muh, I can't quite tell. Can you use another color or something.

[21:17:49.0000] <Hixie>
don't worry about it

[21:17:58.0000] <Hixie>
it's not critical

[21:18:08.0000] <Hixie>
oh... i see what it's doing

[21:18:09.0000] <Hixie>
interesting

[21:18:13.0000] <kennyluck>
Hixie, oh yeah. It's navy.

[21:18:18.0000] <Hixie>
k, cool, thanks

[21:21:20.0000] <mthz>
Hixie: Are you aware of a copy of those tests that mirrors the spec? They look way out of date. It even looks like the validator.nu code mimcs this behavior

[21:21:46.0000] <Hixie>
do you have an example of something out of date?

[21:21:58.0000] <Hixie>
i'm sure they're not perfectly up to date, but my understanding was that those were the latest tests

[21:22:00.0000] <mthz>
Yeah, or maybe I'm just misreading the spec.. I'll paste

[21:22:32.0000] <mthz>
Test: Entity in attribute without semicolon ending in i (test1.test): Input=<h a='&noti'>

[21:23:00.0000] <mthz>
It expects that to yield an error presumably b/c the matched entity didn't end with ';' and has ascii after the last match

[21:23:04.0000] <mthz>
but the spec doesn't say to emit an error

[21:23:21.0000] <mthz>
bunch of entity related tests like that that all expect similar errors when my reading of the spec doesn't suggest there should be any

[21:24:51.0000] <Hixie>
/me looks at the spec

[21:25:14.0000] <Hixie>
(in general i wouldn't be surprised if the error count was more out of date that the expected DOM tree, fwiw)

[21:25:52.0000] <mthz>
i'm only running the tokenizer tests -- not the tree builder -- but yes, i agree. I think all of the out-datedness I've seen is related to error counts

[21:26:46.0000] <Hixie>
what does it say the output should be for that test?

[21:27:05.0000] <mthz>
"output":["ParseError", ["StartTag", "h", {"a":"&noti"}]]},

[21:27:25.0000] <mthz>
I think that's correct save for the parse error

[21:27:32.0000] <Hixie>
yeah, i think you're right

[21:27:40.0000] <Hixie>
do you know when the test was updated?

[21:27:46.0000] <Hixie>
that part of the spec was changed at some point

[21:27:52.0000] <Hixie>
to make it not an error

[21:28:12.0000] <mthz>
sep 24 2009 ;-)

[21:28:34.0000] <mthz>
makes sense then

[21:29:01.0000] <mthz>
I guess I'll compile a list of the ones I come across and log a bug for html5lib

[21:29:42.0000] <Hixie>
while you're at it, add a test for "&not=" (also not a parse error and not treated as an entity) if it's not there already

[21:30:05.0000] <Hixie>
that was changed april 2010

[21:30:52.0000] <Hixie>
looks like as of 2009 it was already not a parse error though

[21:31:12.0000] <mthz>
unfortunately I can't update the html5lib code itself -- probably a bad idea to update the tests and not fix the code

[21:31:26.0000] <Hixie>
well if the test is wrong the test is wrong :-)

[21:31:40.0000] <mthz>
heh

[21:32:09.0000] <mthz>
fwiw, not sure if you saw above, but Henry Sivonen's validator.nu code shows the same vehavior for all of the false negatives i've found

[21:32:20.0000] <mthz>
i'll send them mail

[21:32:23.0000] <mthz>
thanks hixie

[21:32:46.0000] <MikeSmith>
mthz: you know that's actually the same code that Firefox uses

[21:32:50.0000] <MikeSmith>
html parser code

[21:33:07.0000] <mthz>
Mike: the code is semantically correct -- it's merely error reporting which i don't think ever surfaces in the browser

[21:33:12.0000] <MikeSmith>
ah

[21:33:17.0000] <MikeSmith>
yeah, true

[21:33:39.0000] <Hixie>
ah i was wrong, the change was in r4960, also april 2010

[21:33:58.0000] <Hixie>
the change to make it not a parse error i mean

[21:34:03.0000] <mthz>
MikeSmith: random question, but do/did you work for google? i think we may have met before =)

[21:34:17.0000] <Hixie>
and r4959 was the revision that made = act like a-z in attributes

[21:34:51.0000] <MikeSmith>
mthz: there's a different Mike Smith who was a product manager for Chrome

[21:34:51.0000] <Hixie>
mthz: anyway, in any e-mail you said please let them know r4959 and r4960, to make it easier for them to track it

[21:35:11.0000] <mthz>
mike: ahh -- that's the one

[21:35:13.0000] <mthz>
hixie: will do.. thanks

[21:35:20.0000] <Hixie>
thank _you_!

[21:35:40.0000] <mthz>
for my own reference -- what repository do those revisions refer to?

[21:35:45.0000] <Hixie>
whatwg

[21:35:49.0000] <Hixie>
svn.whatwg.org/web-apps

[21:35:50.0000] <mthz>
figured.. thanks

[21:35:51.0000] <mthz>
later all

[21:35:54.0000] <Hixie>
later

[21:39:38.0000] <Hixie>
why do Opera and Chrome (not Safari) return 0 for document.createElement('canvas').getContext('2d').moveTo.length

[21:39:47.0000] <Hixie>
Firefox and Safari get it right

[21:39:48.0000] <Hixie>
(2)

[21:47:08.0000] <Hixie>
ok the change i just made to the spec is for a ridiculously complicated edge case. it's crazy that that is web-compat-critical.

[21:47:30.0000] <heycam>
O_o

[21:48:40.0000] <Hixie>
it's specifically for the case of an inline <script> that executes while the parser is re-entrantly parsing due to a document.write() call, in the case of there being a <link rel=styleesheet> pending that is itself blocking script execution.

[21:49:02.0000] <Hixie>
and it controls whether or not that nested inline script blocks or not.

[21:49:10.0000] <Hixie>
s/controls/affects/

[21:49:24.0000] <heycam>
oh, sorry I thought you specced the moveTo.length being 0

[21:49:27.0000] <Hixie>
the HTML parser, i mean

[21:49:33.0000] <Hixie>
heycam: no, no, that'd be crazy.

[21:49:40.0000] <heycam>
yes :)

[21:49:41.0000] <zewt>
yeah. *that* would be crazy

[21:49:45.0000] <zewt>
*cough*

[21:49:49.0000] <Hixie>
:-P

[22:48:04.0000] <annevk>
Does anyone know what hg-git is called in MacPorts?

[22:56:27.0000] <MikeSmith>
annevk: py27-hggit

[22:56:50.0000] <annevk>
Thanks, I ended up using easy_install

[22:59:14.0000] <zcorpan>
Hixie: opera gets .length wrong (is 0) all over the place. known bug, low prio.

[23:00:46.0000] <Hixie>
it makes feature detection for new features that consisted of adding an optional argument harder

[23:00:54.0000] <Hixie>
if that helps bump up the prio

[23:03:10.0000] <annevk>
MikeSmith: how do you authenticate for github?

[23:03:18.0000] <MikeSmith>
ssh

[23:03:29.0000] <annevk>
MikeSmith: I have the hg push ssh+git:// thingie, but how do I pass username/password?

[23:05:42.0000] <annevk>
ah found it

[23:06:42.0000] <jgraham>
Hixie: Does anyone apart from you try to do feature detection in that way? I imagine not if Chrome and Opera both get it wrong

[23:07:21.0000] <Hixie>
if opera and chrome didn't get it wrong, it would be a good way to do it for e.g. the new arcTo()

[23:07:28.0000] <Hixie>
but yeah, i don't think anyone actually does it

[23:09:03.0000] <jgraham>
annevk: (I don't recommend the hg push ssh+git method, but if it worked for MikeSmith maybe it's fine)

[23:10:20.0000] <MikeSmith>
jgraham, annevk : what I'm using for the current mirroring to github/w3c is this:

[23:10:22.0000] <MikeSmith>
hg bookmark -d master

[23:10:22.0000] <MikeSmith>
hg bookmark -fr default master

[23:10:23.0000] <MikeSmith>
hg gexport

[23:10:24.0000] <MikeSmith>
git push github master

[23:11:01.0000] <jgraham>
Yes, I was going to say that hg gexport worked better for me

[23:11:08.0000] <jgraham>
I just had to look up what it was

[23:11:19.0000] <annevk>
my main problem is authentication

[23:11:23.0000] <annevk>
the rest seems to work fine

[23:11:51.0000] <jgraham>
Hmm, but for github authentication should be key-baed

[23:11:55.0000] <jgraham>
*key-based

[23:12:15.0000] <jgraham>
You shouldn't need to add username or pw anywhere

[23:12:57.0000] <zcorpan>
annevk: http://krijnhoetmer.nl/irc-logs/whatwg/20120827#l-771

[23:13:03.0000] <jgraham>
That is, if you set up the right keys on your computer per the instructions on github

[23:13:20.0000] <jgraham>
Then do what MikeSmith said up to the last but one step

[23:13:24.0000] <annevk>
github says https is recommended

[23:13:47.0000] <jgraham>
Then git remote add origin git⊙gc:whatwg/dom.git

[23:13:47.0000] <jgraham>
git push -u origin master

[23:14:48.0000] <jgraham>
Since I just copied/pasted that bit from the github page I'm sure it's fine

[23:20:39.0000] <divya>
jgraham: !!1 just wanted to check if you are on track to be in paris

[23:20:41.0000] <divya>
for the event

[23:20:54.0000] <divya>
and hoping you could give a talk too while at it

[23:21:52.0000] <jgraham>
divya: Yes, and yes

[23:22:41.0000] <divya>
jgraham: sweet i will put you in touch with someone who wanted to find out what you would be talking aobout. hurray.

[23:25:06.0000] <jgraham>
divya: Cool

[23:25:22.0000] <Ms2ger>
/me approves

[23:25:41.0000] <divya>
:)) Ms2ger do you ever make an IRL appearance?

[23:25:52.0000] <divya>
MikeSmith: would you also be at TPAC?

[23:26:09.0000] <MikeSmith>
hey divya

[23:26:14.0000] <MikeSmith>
yeah, will be there

[23:26:23.0000] <divya>
so also for Test the Web Forward then MikeSmith ?

[23:26:25.0000] <divya>
:PPP

[23:26:32.0000] <divya>
you should ideall

[23:26:33.0000] <divya>
y

[23:26:43.0000] <Ms2ger>
Ever? Maybe

[23:27:08.0000] <divya>
ahaha :)

[23:28:01.0000] <MikeSmith>
divya: what's the dates?

[23:28:14.0000] <divya>
MikeSmith: 26-27 oct

[23:28:19.0000] <divya>
just before TPAC

[23:28:37.0000] <divya>
hold on it should be on csswg wiki

[23:29:04.0000] <divya>
MikeSmith: http://wiki.csswg.org/test/events/paris-2012

[23:29:35.0000] <divya>
MikeSmith: this is the internal organizational thing we will have the website ready by end of the week

[23:29:58.0000] <MikeSmith>
I see

[23:30:55.0000] <jamesr_>
othermaciej: i believe the wiki proposal for unrelated context does address your question about noreferrer

[23:31:03.0000] <jamesr_>
othermaciej: http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts#Current_Usage_and_Workarounds

[23:31:27.0000] <Ms2ger>
divya, s/Glassman/Glazman/?

[23:31:35.0000] <divya>
ahaha Ms2ger yes >_>

[23:31:48.0000] <othermaciej>
I see

[23:32:11.0000] <othermaciej>
jamesr_: is there a difference other than whether the Referer header is sent?

[23:32:34.0000] <divya>
Ms2ger: the person who has been updating the wiki doesnt know the members >_> i will have to dig out my credentials from the dark corners of my email archive

[23:32:44.0000] <Ms2ger>
Oh dear :)

[23:32:49.0000] <jamesr_>
assuming noreferrer nulls out the window.opener, etc, i don't think so

[23:33:21.0000] <othermaciej>
jamesr_: also is it really ok to drop support for the window.opener behavior of noreferrer? that seems bold

[23:34:12.0000] <jamesr_>
you mean with rel=noreferrer and target=_blank ?

[23:34:18.0000] <divya>
Ms2ger: or glazou can edit it himself :PP

[23:34:30.0000] <divya>
Ms2ger: i can assure you though he is pretty sharp and planned the first one.

[23:34:35.0000] <jamesr_>
we've been doing it in chromium for several years, i don't know if i was around to know if we got compat issues when we started doing that

[23:35:09.0000] <othermaciej>
jamesr_: yes, the requirement to null out window.opener as per http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer

[23:35:37.0000] <othermaciej>
jamesr_: the wiki section you cited seems to suggest that this behavior of rel=noreferrer could be removed

[23:35:48.0000] <jamesr_>
oh i see. i don't know about that

[23:35:51.0000] <othermaciej>
which seems all kinds of wrong to me

[23:35:58.0000] <jamesr_>
i thought you were referring to the nulling out behavior, which i think is fine

[23:36:17.0000] <othermaciej>
yes, the nulling behavior is good and I think a logical corollary of not sending referrer

[23:36:37.0000] <othermaciej>
and also it's probably relied on by more than just gmail

[23:36:45.0000] <jamesr_>
oh i'm sure

[23:36:54.0000] <jamesr_>
i can't find anything in the proposal suggesting that noreferrer would stop doing this

[23:38:30.0000] <othermaciej>
oh, I misread

[23:38:43.0000] <annevk>
zcorpan: so yeah it was the caching :/

[23:38:48.0000] <annevk>
guess I'll just empty the cache again

[23:38:51.0000] <othermaciej>
I was looking at "Google Chrome also has a non-standard trick for opening links in a new process by using window.open(), setting the resulting window's opener to null, and then navigating the new window to a different site"

[23:39:08.0000] <jamesr_>
ah gotcha

[23:39:14.0000] <jamesr_>
yeah that's a way to get the unrelated behavior with window.open()

[23:39:19.0000] <jamesr_>
as opposed to a link

[23:39:46.0000] <zcorpan>
annevk: is it possible to prune the cache automatically (or empty it once a every few months automatically)?

[23:39:46.0000] <jamesr_>
that's also a behavior other pages probably use now

[23:39:53.0000] <jamesr_>
(and one that not-so-infrequently breaks with gmail, heh)

[23:40:00.0000] <othermaciej>
does that method result in sending Referer or no?

[23:40:03.0000] <othermaciej>
I can't tell

[23:40:13.0000] <annevk>
zcorpan: I guess, but I'm fine with this

[23:40:16.0000] <othermaciej>
the page says gmail uses that technique, but I would be surprised if a mail client wanted to send referer

[23:40:21.0000] <othermaciej>
as that seems like a privacy issue

[23:40:34.0000] <annevk>
zcorpan: I'd rather we remove the cache, but maybe that would be too much of a hit on the SVN server

[23:40:43.0000] <jamesr_>
depends on what it is, you can sanitize the URL with a redirect

[23:41:21.0000] <jamesr_>
i'll bet if you asked charlie reis he'd know the answer to all of these sorts of questions. this particular behavior is tricky to implement and i'm not super familiar

[23:41:59.0000] <othermaciej>
I'm in fact trying to ask him questions via email on the whatwg list

[23:42:42.0000] <annevk>
zcorpan: might actually have been a hiccup from the SVN server too

[23:43:13.0000] <jamesr_>
the proposal does mention supporting rel="…" in general for window.open() would be useful. then you could just set noreferrer and there'd be no question about what happens

[23:44:57.0000] <othermaciej>
that part of the proposal seems ok to me (though only a small subset of link relations seem like they would be relevant in that usage)

[23:45:55.0000] <othermaciej>
I'm just not really clear on when you would want the "unrelated" behavior instead of "noreferrer"

[23:47:21.0000] <othermaciej>
I am puzzled that he implies mail clients would want it, as sending referer with the url of the mail client seems clearly bad

[23:53:09.0000] <jamesr_>
othermaciej: the use case was google reader

[23:53:25.0000] <jamesr_>
or imagine some sort of content aggregator app

[23:53:39.0000] <jamesr_>
seems pretty reasonable to send a referer from my rss reader to the page

[23:54:21.0000] <othermaciej>
most content aggregators I use don't presume to open windows for me, but if they did, I guess I could see how they'd want to null opener but still send referer

[00:46:39.0000] <Ms2ger>
annevk, <annevk> please someone remind me tomorrow

[00:48:08.0000] <jgraham>
We are reminding annevk that it is tomorrow?

[00:49:00.0000] <zcorpan>
Ms2ger: it's already fixed

[00:49:11.0000] <Ms2ger>
Ah, good

[00:49:56.0000] <Ms2ger>
Also, nobody ever uses function.length

[00:53:07.0000] <jgraham>
Hixie: http://damowmow.com/playground/demos/document-write-and-scripts/002.html in Opera gives me 0 2 2

[01:40:55.0000] <jgraham>
So, if you document.write in the load event, how many history entries should you end up with? Spec/firefox/IE say 2 (one before the write, one after), Opera/WebKit say 1 (after the write)

[01:41:23.0000] <jgraham>
Is there any reason the spec behaviour is more useful? AFAICT it usually breaks the back button

[01:42:24.0000] <jgraham>
<script>onload = function() {document.write("Go back and this will be rerun, so you will end up in the same place")}</script>

[01:48:02.0000] <zcorpan>
Ms2ger: that's why it's low prio :-)

[02:05:41.0000] <gsnedders>
Ms2ger: Test suites use Function.length!

[02:07:08.0000] <zcorpan>
gsnedders: that's why it's a known bug :-P

[03:58:51.0000] <zcorpan>
so, w3c -= annevk

[04:03:48.0000] <beverloo>
his new company just needs to join as a member :p

[04:04:08.0000] <beverloo>
it's disturbing nonetheless

[04:05:01.0000] <jgraham>
It's not surprising

[04:07:41.0000] <jgraham>
Perhaps W3C will eventually learn that their craziness is bad if it has consequences

[04:07:55.0000] <jgraham>
Although it didn't work so well with HTML

[04:08:12.0000] <jgraham>
With the whole fork -> unfork -> fork thing

[04:53:33.0000] <withub>
Is there any way to get the noreferrer relation to work on a script tag?

[04:54:05.0000] <withub>
so that when the src of the script tag is fetched from the remote server, a referer won't be set?

[04:54:06.0000] <withub>
s/set/sent

[04:56:43.0000] <annevk>
beverloo: the Member Agreement is not much better

[07:13:56.0000] <jgraham>
Hixie: Is there a difference between the behaviour in bug 18459 and just updating the document base to be the new document base on pushState unless there is a base element in which case not updating it?

[07:14:12.0000] <jgraham>
s/to be the new document base/to be the new document address/

[09:03:53.0000] <dglazkov>
good morning, Whatwg!

[10:21:44.0000] <Hixie>
jgraham: changing the <base> element dynamically presumably also affects things

[10:22:09.0000] <Hixie>
jgraham: (re document.write, weird, i guess that changed at some point? i must have an older opera at home)

[10:34:39.0000] <annevk>
Hixie: just to be clear, you prefer html.spec.whatwg.org over what we have today?

[10:34:49.0000] <annevk>
Hixie: I guess that works too

[10:35:31.0000] <annevk>
Hixie: it's a little bit more hassle with the DreamHost people and becomes semi-problematic if editors change

[10:35:42.0000] <Hixie>
it's mostly because that gives the editors complete control over the subdomain, and i don't have to worry about managing anything or worrying about security

[10:35:51.0000] <Hixie>
why is there any hassle with dreamhost?

[10:36:03.0000] <Hixie>
/me has 60+ subdomains, and is pretty used to it :-P

[10:36:13.0000] <annevk>
there was last time I think, because you assigned the subdomain directly to me

[10:36:28.0000] <Hixie>
changing editors is a concern, true, but the solution then is _don't change editors_ :-P pick up a responsibility and keep it for life :-P

[10:36:41.0000] <Hixie>
oh right, yeah, if we do that it's a bit more complex

[10:36:51.0000] <Hixie>
i figured we'd just have users under my account

[10:37:00.0000] <TabAtkins>
"The spec editor mates for life with their chosen spec."

[10:38:10.0000] <Ms2ger>
TabAtkins, fortunately we don't require picking a single spec...

[10:38:36.0000] <Hixie>
annevk: anyway, if it's all in a github repo it's not a huge deal if the editors change, you just wipe the directory and have hte new one do their stuff afresh :-)

[10:38:50.0000] <TabAtkins>
Nor do we require a single editor per spec.  It's a happy polyamarous family.

[10:38:57.0000] <annevk>
Hixie: fair enough

[10:39:14.0000] <Hixie>
/me is of the opinion that if you can be editing multiple specs, your spec isn't big enough, and multiple editors means diluted blame, which is even worse :-P

[10:39:16.0000] <TabAtkins>
The relationship graph of editors and specs is K2, luckily.

[10:39:37.0000] <TabAtkins>
Hixie: I edit one spec, it's just split up into multiple documetns.

[10:39:41.0000] <Hixie>
hah

[10:48:57.0000] <jgraham>
Hixie: Yeah, changing the base is an interesting case I guess

[10:52:58.0000] <Hixie>
any opera people around with opinions on <template>?

[10:53:13.0000] <Hixie>
as in http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#introduction

[10:53:24.0000] <Hixie>
trying to work out whether to put it in the html spec or not

[10:53:46.0000] <TabAtkins>
Hixie: The only person we know of who's cared about it from Opera is jgraham.

[10:53:57.0000] <jgraham>
Hixie: Something like http://hoppipolla.co.uk/tests/pushState/003.html ?

[10:54:05.0000] <annevk>
well "cared" would also include me :p

[10:54:08.0000] <TabAtkins>
At least, in mailing lists so far.

[10:54:16.0000] <TabAtkins>
But you're not Opera, so there.

[10:54:36.0000] <jgraham>
Hixie: What sort of opinion are you looking for here?

[10:54:40.0000] <Hixie>
(i hate the way pushState() tests make it hard to view source in some browsers :-P)

[10:54:42.0000] <annevk>
TabAtkins: :)

[10:54:42.0000] <zewt>
i'm doing templating-in-markup already; i just stick my templates in a @hidden block, then clone its contents into a DocumentFragment

[10:54:49.0000] <Hixie>
jgraham: go/no-go, or anything more detailed

[10:55:06.0000] <TabAtkins>
zewt: That's problematic if you want to avoid loading resources. :/

[10:55:06.0000] <zewt>
doesn't have nice magical syntax for filling in contents, but that's easy enough with querySelector

[10:55:28.0000] <jgraham>
I don't think that we object to the idea of web components or templates, but we might of course want to argue about the details

[10:55:28.0000] <zewt>
TabAtkins: i guess; in my case I do want everything preloaded

[10:56:00.0000] <jgraham>
So no objection to adding it to the HTML spec if that is generally considered to be the best home for it

[10:56:32.0000] <TabAtkins>
zewt: Okay.  More generally, if you're stamping out templated html multiple times, you may want to vary a resource location in each stamp, like <img src='image{i}'> or whatever.

[10:56:33.0000] <zewt>
TabAtkins: my first instinct is that you should be able to (somehow) say something like "@hidden and also don't load resources for this hidden element", though of course that's far more complicated than @hidden today

[10:56:43.0000] <jgraham>
(if that was a vauge answer, it was a vauge question :p)

[10:56:49.0000] <Hixie>
jgraham: ok

[10:57:01.0000] <zewt>
i do that, eg. var newInstance = copyTemplate(template); newInstance.querySelector("img.some-image").src = image[i]

[10:57:18.0000] <Hixie>
jgraham: any objection in particular to the proposed parsing mechanism (parsing "children" of <template> into an anonymous separate document)?

[10:57:38.0000] <zewt>
like I said it's not as pretty as a more thorough templating system might be able to make it, but it's been working pretty well

[10:59:10.0000] <TabAtkins>
zewt: That's basically what <template> does. ^_^

[10:59:13.0000] <Hixie>
jgraham: yeah, that test is exactly what i meant

[10:59:17.0000] <Hixie>
jgraham: very interesting

[10:59:18.0000] <TabAtkins>
(re: hidden and don't load resources)

[10:59:33.0000] <TabAtkins>
(also, don't allow querySelector and friends to match into it)

[10:59:35.0000] <zewt>
TabAtkins: seems like it might be a useful thing in general, even without templates

[11:00:44.0000] <jgraham>
Hixie: I don't have a strong objection to the magical parsing. I am aware that hsivonen does and I think his argument has merit, but I don't have an alternative design for the feature that is better

[11:00:58.0000] <Hixie>
jgraham: chrome and firefox are freakishly interoperable on that test given the lack of basis for their behaviour in any spec

[11:01:09.0000] <Hixie>
jgraham: k

[11:01:26.0000] <dglazkov>
Hixie: you may want to check with Tony Russ and Rafael Weinstein who have been actively working on this spec first.

[11:01:51.0000] <jgraham>
Hixie: I hate things that are freakishly interopable but contradict all known specs :)

[11:02:11.0000] <Hixie>
dglazkov: i am in close contact with rafael

[11:02:16.0000] <dglazkov>
Hixie: great!

[11:02:21.0000] <dglazkov>
how close? :P

[11:02:44.0000] <Hixie>
he's one of the only people i've had a video conf call with this year :-P

[11:02:49.0000] <dglazkov>
whoa

[11:02:51.0000] <Hixie>
possibly in fact the only person :-P

[11:02:56.0000] <Hixie>
more than once!

[11:03:38.0000] <dglazkov>
btw, we spoke with other Mozillians (bz, sicking), and they don't think the magic parsing design is bad.

[11:03:58.0000] <dglazkov>
but raf would have a much more detailed information on that meeting

[11:04:02.0000] <Hixie>
k

[11:04:11.0000] <Hixie>
(hopefully they can let me know that directly, too)

[11:04:36.0000] <dglazkov>
I think raf is planning to send another mail to the list about that

[11:04:55.0000] <Hixie>
k

[11:26:05.0000] <JVoracek>
 

[12:39:14.0000] <annevk>
since I put my email at the top of the MetaExtensions page instead of getting emails about registering new users people complain about validation errors and wonder how to fix those

[12:39:41.0000] <annevk>
I might leave remove my email address again Hixie and only deal with those people that ask for an account on IRC

[12:40:35.0000] <annevk>
heh, scumbag steve

[12:41:56.0000] <TabAtkins>
annevk: Yeah, change the message to be "come to IRC and ask"

[12:42:28.0000] <zewt>
put a 4-page algorithm for deriving your email address

[12:45:47.0000] <annevk>
TabAtkins: done

[12:51:16.0000] <charlvn>
annevk: so you still unemployed?

[12:51:54.0000] <annevk>
charlvn: gonna start doing some work next week, but no pay for now

[12:52:17.0000] <annevk>
no need for money at the moment

[12:52:27.0000] <charlvn>
taking a break every now and then is a good thing

[12:52:31.0000] <charlvn>
enjoy it while it lasts :)

[12:52:53.0000] <annevk>
it's been a good two months so far :)

[12:53:14.0000] <charlvn>
nice

[12:54:19.0000] <annevk>
charlvn: are you actually in the Netherlands these days?

[12:54:41.0000] <charlvn>
annevk: haven't been outside of the EU in almost a year

[12:54:59.0000] <annevk>
should visit one of those Fronteers meetups one day

[12:55:19.0000] <charlvn>
i have been putting it off but it's a good idea

[12:55:28.0000] <charlvn>
thanks for reminding me

[12:55:30.0000] <annevk>
and time it appropriately so we can meet, would love to learn some more Afrikaans :)

[12:55:46.0000] <charlvn>
lol my afrikaans has gone down the drain :S

[12:56:20.0000] <annevk>
too bad, together with Belgian I think it's more Dutch than Dutch

[12:56:51.0000] <charlvn>
well they like to translate things "properly", not just take english words over

[12:57:08.0000] <charlvn>
actually i find it rather painful

[12:57:16.0000] <annevk>
right, Dutch is borrowed all over

[12:57:30.0000] <charlvn>
when i try to use software in afrikaans the number of wtfs per minute is pretty high

[12:57:37.0000] <charlvn>
i don't understand half of the application anymore

[12:57:39.0000] <annevk>
and even made less Dutch (kado -> cadeau)

[12:57:45.0000] <annevk>
haha

[12:58:18.0000] <annevk>
admittedly I only use English software

[12:58:39.0000] <charlvn>
at work we have this application, the dutch translation pack has been bought from belgium

[12:58:51.0000] <charlvn>
none of us use it, we immediately switch to english

[12:59:23.0000] <charlvn>
we just talk of a "policy", not a "beleid" so it confuses us :)

[13:04:00.0000] <divya>
hey whatwg what is jgraham 's email id

[13:04:06.0000] <divya>
/me is lazy to check mailing list.

[13:04:11.0000] <gsnedders>
divya: For Opera? jgraham .

[13:04:18.0000] <divya>
gsnedders: yes. o thnx.

[13:04:25.0000] <divya>
jgraham@o i suppose

[13:04:29.0000] <gsnedders>
Yeah.

[13:05:56.0000] <divya>
thnx gsnedders

[13:06:49.0000] <gsnedders>
divya: PS: I am now your LDAP directory.

[13:07:01.0000] <gsnedders>
*not

[13:07:38.0000] <annevk>
not hers, but for #whatwg you are :p

[13:08:55.0000] <gsnedders>
:(

[13:10:07.0000] <jgraham>
gsnedders: You have many things in common with LDAP

[13:10:17.0000] <jgraham>
Like no one actually understands how you work

[13:13:30.0000] <jgraham>
divya: I got your email, thanks

[13:13:51.0000] <divya>
gsnedders: :)))))

[13:13:58.0000] <divya>
jgraham: AHAHAHA poor gsnedders

[13:14:05.0000] <jgraham>
I guess you are expecting me to reply

[13:14:08.0000] <divya>
but it is true you are mysteriously magical gsnedders MUCH LIKE LDAP

[13:14:23.0000] <divya>
jgraham: not immediately no. email is not Instant Messaging :P

[13:14:26.0000] <divya>
or Text or call.

[13:14:40.0000] <divya>
/me wonders how many media of communication exist

[13:15:33.0000] <jgraham>
divya: You are not expecting me to reply at all, or I should wait some unspecified time to make it sufficiently async to fit your notion of what is appropriate for email? :)

[13:15:45.0000] <divya>
jgraham: REPLY WHEN YOU PLEASE

[13:15:58.0000] <divya>
jgraham: or whenever is convenient!!!

[13:16:09.0000] <divya>
/me takes note of jgraham's penchant for nitpicking

[13:16:43.0000] <annevk>
not a fan of dubstep, but http://www.youtube.com/watch?v=WgII2gDY-Rw is hilarious

[13:17:21.0000] <jgraham>
dglazkov: Is this your "implement Web Components or die" expression? https://lh4.googleusercontent.com/-utqdXXy_BGU/UDuu7l702AI/AAAAAAAAKKM/-ptCs0_sffU/s657/IMG_20120827_101442.jpg

[13:17:33.0000] <annevk>
especially the woman in pink is great

[13:17:58.0000] <dglazkov>
jgraham: the only response to this that I can have is: https://lh4.googleusercontent.com/-utqdXXy_BGU/UDuu7l702AI/AAAAAAAAKKM/-ptCs0_sffU/s657/IMG_20120827_101442.jpg

[13:18:15.0000] <dglazkov>
or it's emoticon equivalent, <_<

[13:18:51.0000] <divya>
ahahahaha dglazkov

[13:19:02.0000] <divya>
annevk: is this the video you have been recommending since morning

[13:19:16.0000] <annevk>
your morning, my early evening :)

[13:19:45.0000] <annevk>
just passing on the greatness showed to me by robbert

[13:21:15.0000] <divya>
that lady in pink is bestest

[13:25:16.0000] <gsnedders>
jgraham: I work in the same manner as most people in this industry: by hitting keys on a keyboard.

[14:01:11.0000] <Hixie>
annevk: weird, i've only ever had people asking for accounts


2012-08-29
[22:25:46.0000] <zcorpan>
TabAtkins: specs choose their editors

[22:51:15.0000] <kennyluck>
TabAtkins, do you have a saved version of your test? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1724 gives me red too, on Chrome 23.

[02:22:36.0000] <jgraham>
http://lists.w3.org/Archives/Public/public-coremob/2012Aug/0048.html

[02:23:00.0000] <jgraham>
So I guess that is one indication of who will be the HTML Technical Editor

[02:23:11.0000] <jgraham>
or whatever the W3C job title was

[02:24:25.0000] <jgraham>
s/will/could/

[02:46:14.0000] <kennyluck>
jgraham, "so I have hope that we will meet again". If that's the W3C job, wouldn't the chance of meeting again be like s/I have hope that//?

[02:47:58.0000] <jgraham>
kennyluck: Perhaps, or perhaps it is understatement

[02:48:16.0000] <jgraham>
This is kind of pointless speculation ofc

[02:48:37.0000] <kennyluck>
*shrug*

[03:02:02.0000] <annevk>
jgraham: the stars say yes, but it's been a while since I checked

[03:03:26.0000] <darobin>
jgraham: it's speculation almost to the point of being kremlinology :)

[03:03:37.0000] <jgraham>
annevk: You use astrology to try and figure out the W3C? I guess it might be a unique case where it isn't less accurate than other methods…

[03:06:35.0000] <darobin>
kennyluck: or perhaps it is just that CoreMob doesn't meet at TPAC and other such regular gatherings that I usually attend (see http://lists.w3.org/Archives/Public/public-device-apis/2012Aug/0097.html)

[03:07:42.0000] <annevk>
darobin: still hoping for you to start that movie career one day

[03:08:18.0000] <darobin>
annevk: oh, I had no idea you wanted to get rid of me *that* bad

[03:08:41.0000] <annevk>
get rid of you? I want to see the output :)

[03:09:23.0000] <darobin>
aww sweet

[03:10:03.0000] <jgraham>
When you say "movie" are you thinking "arthouse French movie with lots of nudity"?

[03:10:10.0000] <darobin>
well hey, if jgraham's speculation is right, maybe I can just let the WHATWG work and spend the time writing a movie ;)

[03:10:24.0000] <darobin>
jgraham: why bother with arthouse?

[03:10:53.0000] <annevk>
jgraham: what are you implying?

[03:11:15.0000] <annevk>
darobin: easy money :)

[03:11:34.0000] <jgraham>
darobin: Is there such a thing as a non-arthouse French movie?

[03:11:41.0000] <annevk>
(and successfully done already, minus the movie, see e.g. P2P APIs)

[03:11:50.0000] <annevk>
jgraham: Taxi

[03:12:15.0000] <annevk>
jgraham: also Taxi 2 and Taxi 3

[03:12:25.0000] <darobin>
jgraham: oh, yeah, plenty — Taxi is only the start of it

[03:12:32.0000] <annevk>
whoa, there's even Taxi 4

[03:12:37.0000] <annevk>
not sure I've seen that

[03:12:45.0000] <darobin>
/me doesn't believe he was ever getting paid for anything to do with P2P APIs

[03:13:24.0000] <annevk>
Intouchables was an awesome recent French movie

[03:13:58.0000] <annevk>
darobin: I was referring to letting WHATWG do the work and then publish it elsewhere

[03:14:04.0000] <darobin>
I quite liked it, though I wouldn't go for awesome just yet — awesome acting though

[03:14:23.0000] <darobin>
annevk: yeah, but how useful is that if it doesn't involve profit ;-)

[03:14:46.0000] <annevk>
prolly got the W3C some extra Members

[03:14:54.0000] <annevk>
"we're doing P2P now! join us"

[03:15:43.0000] <annevk>
HTML5 put the W3C in the center of the developer community again too

[03:16:26.0000] <darobin>
ayup

[03:16:53.0000] <darobin>
that's why I was thinking about NextStand, to show what the steps after OpenStand are

[03:17:06.0000] <darobin>
but I'm not motivated enough to take it much beyond a tweet

[03:17:34.0000] <darobin>
annevk: how much of you will we be seeing around?

[03:17:35.0000] <annevk>
I was gonna reply with "WHATWG" but then Twitter failed me

[03:18:04.0000] <annevk>
seems like not much in the W3C environment http://lists.w3.org/Archives/Public/www-archive/2012Aug/0028.html

[03:18:37.0000] <annevk>
now I'm not getting paid by any Members I don't really feel like giving in on stuff I believe in

[03:19:51.0000] <annevk>
but I'll give them some time to properly reply before doing anything drastic

[03:19:56.0000] <darobin>
WHATWG isn't where I would see NextStand just yet, though closer on a number of aspects for sure

[03:20:03.0000] <annevk>
not like I'm in a hurry

[03:20:11.0000] <darobin>
yeah I saw that post, I was just wondering in general

[03:28:46.0000] <annevk>
haha, where did marcosc say that?

[03:30:28.0000] <annevk>
ah found it

[03:31:09.0000] <annevk>
http://lists.w3.org/Archives/Public/spec-prod/2012JulSep/0020.html

[08:24:37.0000] <Ms2ger>
TabAtkins, not here...

[08:24:47.0000] <Ms2ger>
(Re "our parsing is officially retarded.")

[08:37:39.0000] <dglazkov>
good morning, Whatwg!

[11:57:14.0000] <Hixie>
annevk?

[11:59:30.0000] <Ms2ger>
Doesn't look like it

[12:01:07.0000] <Hixie>
if i do a same-origin xhr that results in a redirect to another origin, does it always fail?

[12:01:50.0000] <Hixie>
oh, no, i see

[13:25:17.0000] <JonathanNeal>
Word.

[13:25:30.0000] <JonathanNeal>
TabAtkins: Did you catch my gist with the notes?

[14:24:18.0000] <wycats>
Has anyone given any thought to making it possible to indicate a list of supported events via WebIDL (other than via event handler IDL attributes)?

[14:35:24.0000] <jamesr>
wycats, what's your definition of supported?

[14:36:01.0000] <jamesr>
you can construct an event with any sort of name and dispatch it at any EventTarget in JS if you like

[16:03:30.0000] <wycats>
jamesr: but you can't say "this interface supports an event named foo"

[16:03:40.0000] <wycats>
which is actually a useful thing to be able to know

[16:05:50.0000] <Hixie>
what does that mean?

[16:05:53.0000] <jamesr>
what do you mean by "supports" ?

[16:06:03.0000] <jamesr>
it will do something in particular when given an event foo?

[16:06:12.0000] <jamesr>
or it will generate an event foo in some circumstance?

[16:10:22.0000] <Hixie>
and if the latter, which circumstance?

[16:56:54.0000] <JVoracek>
 


2012-08-30
[20:31:20.0000] <wycats>
jamesr: the former

[20:31:25.0000] <wycats>
well

[20:31:29.0000] <wycats>
no

[20:31:37.0000] <wycats>
it means that addEventListener('foo') is meaningful

[20:31:42.0000] <wycats>
foo will ever be generated

[20:31:50.0000] <jamesr_>
foo will be generated by whom?

[20:31:54.0000] <jamesr_>
and in response to what?

[20:32:15.0000] <wycats>
jamesr: the HTML5 spec lists events that are generated by specific elements in certain circumstances, correct?

[20:32:22.0000] <wycats>
let's say HTML spec

[20:32:27.0000] <jamesr_>
do you have a specific example of what object you would ask this question about and what event?

[20:33:21.0000] <wycats>
an HTMLInputElement generates a change event

[20:33:32.0000] <wycats>
addEventListener

[20:33:38.0000] <wycats>
addEventListener('change') is meaningful

[20:33:47.0000] <wycats>
while addEventListener('wtf') is meaningless

[20:33:56.0000] <wycats>
the list of supported events is part of the interface of an object

[20:33:58.0000] <jamesr_>
why - i could construct a 'wtf' event and fire it at your <input> event

[20:34:31.0000] <wycats>
jamesr: you could also install an onwtf property on HTMLInputElement.prototype

[20:34:32.0000] <jamesr_>
<input> element, that is

[20:34:35.0000] <wycats>
but that's besides the point

[20:34:38.0000] <jamesr_>
how so?

[20:34:47.0000] <wycats>
the list of events specified by the spec is an important part of the interface

[20:35:19.0000] <jamesr_>
sounds like you want to ask if a given thing will _generate_ an event

[20:35:30.0000] <wycats>
well... I originally asked about WebIDL

[20:35:35.0000] <wycats>
so I don't want to do it via code

[20:35:47.0000] <wycats>
I want to see it in the WebIDL interface for HTMLInputElement

[20:36:16.0000] <jamesr_>
the WebIDL interface is you can register a handle for any event you want

[20:36:24.0000] <jamesr_>
because any event might be fired at the element

[20:36:33.0000] <wycats>
and I'm saying that the fact that only certain events are specified in the spec is an important part of the interface

[20:37:01.0000] <wycats>
I understand that WebIDL doesn't provide a mechanism for doing it today

[20:37:04.0000] <wycats>
but it seems useful

[20:37:10.0000] <jamesr_>
only some events are specified as being fired at the element, but it's in no way an exhaustive list of what could be fired at that element

[20:37:38.0000] <wycats>
it's an exhaustive list of the events that are specified to be fired at the element

[20:37:41.0000] <jamesr_>
it's easy to say "yes, change could be fired at HTMLInputElement" but i have no idea how to decide whether or not wtf

[20:37:44.0000] <jamesr_>
there is no such thing

[20:37:51.0000] <jamesr_>
it's specified that you can fire anything at the element

[20:37:53.0000] <wycats>
jamesr: yes there absolutely is

[20:38:06.0000] <wycats>
jamesr: you can also add any property to the element

[20:38:08.0000] <wycats>
that doesn't matter

[20:38:22.0000] <jamesr_>
why doesn't it matter?

[20:38:23.0000] <wycats>
there is a list of events that the spec says will be fired under certain circumstances

[20:38:30.0000] <wycats>
that list is an important part of the interface

[20:38:40.0000] <wycats>
if you don't think it is, why?

[20:39:05.0000] <Hixie>
there is no such list

[20:39:17.0000] <wycats>
there is an implied list

[20:39:18.0000] <jamesr_>
i think you think there is such a list, and i'm telling you no such thing exists

[20:40:02.0000] <wycats>
throughout the spec, there is language that instructs the user agent to fire an event in certain circumstances

[20:40:22.0000] <wycats>
there is a finite number of those instructions, and they are specified against specific subsets of all available elements

[20:40:50.0000] <wycats>
that means that for a given element, there is a list of events that the spec knows about

[20:40:59.0000] <wycats>
just like there is a list of properties or attributes that the spec knows about

[20:41:03.0000] <jamesr_>
(and any element that's a parent of those elements)

[20:41:40.0000] <wycats>
yes, as a consequence of bubbling

[20:42:14.0000] <wycats>
for a given event target, there is a finite list of events

[20:42:17.0000] <wycats>
that the spec knows about

[20:42:46.0000] <wycats>
the list of events that will be fired directly on an event target is a useful part of the interface

[20:44:35.0000] <jamesr_>
can you give a concrete example?

[20:50:02.0000] <wycats>
probably more readily in person

[20:50:09.0000] <wycats>
this conversation is veering off for me

[20:50:44.0000] <wycats>
I think I could probably make my point if I focused exclusively on extreme precision for a while

[20:52:17.0000] <jamesr_>
i just want to know the one line of code you really want to write

[20:53:36.0000] <zewt>
wycats: no, any event target can receive any event

[20:53:57.0000] <wycats>
jamesr: this is not about lines of code

[20:54:06.0000] <wycats>
it's about reading the spec and understanding something import

[20:54:08.0000] <wycats>
important*

[20:54:13.0000] <Hixie>
wycats: there is language that in at least two places means the set of possible events that can fire on a given object is infinite

[20:54:16.0000] <wycats>
let me try to be precise

[20:54:22.0000] <zewt>
particular apis happen to only fire specific ones, but anyone can dispatch events directly and it's exactly the same (except for a few unfortunate and isolated exceptions)

[20:54:32.0000] <wycats>
Hixie:  there is also language that allows infinite attributes on elements

[20:54:33.0000] <Hixie>
wycats: (namely, dispatchEvent() for any EventTarget, and EventSource's processing model)

[20:54:36.0000] <wycats>
but that is irrelevant

[20:54:54.0000] <Hixie>
wycats: how is it irrelevant? there's similarly no way to detect if a particular attribute can exist on an element :-)

[20:55:18.0000] <wycats>
I am not talking about detection

[20:55:23.0000] <Hixie>
(sorry for only posting occasionally, i'm just popping in during ad breaks here :-) )

[20:55:25.0000] <wycats>
I am talking about formalizing a concept in the spec

[20:55:27.0000] <wycats>
instead of via prose

[20:55:43.0000] <zewt>
events are specified in terms of dispatching--not receiving

[20:55:59.0000] <Hixie>
wycats: what is the concept you want to formalise?

[20:56:57.0000] <wycats>
a list of events that the spec instructs the user agent to fire directly at an event target in some situation

[20:57:05.0000] <wycats>
http://dev.w3.org/html5/spec/single-page.html#the-a-element

[20:57:08.0000] <wycats>
Here, we have a list of attributes

[20:57:13.0000] <wycats>
This is not exhaustive

[20:57:17.0000] <wycats>
the spec allows any attribute

[20:57:32.0000] <jamesr_>
so you want to ask the UA what _it_ might fire at your element

[20:57:39.0000] <wycats>
but there's a list of attributes that have specific meaning in the spec

[20:57:40.0000] <jamesr_>
not ask your element what might be fired at it

[20:57:41.0000] <jamesr_>
right?

[20:57:48.0000] <wycats>
correct

[20:57:58.0000] <wycats>
except that I don't want the answer via code

[20:58:10.0000] <zewt>
wycats: attributes are specified because attributes have meaning *to* the element; events have no meaning to elements (again with a couple exceptions they never do anything when they receive events, except forwarding them to on* attributes of course)

[20:58:17.0000] <wycats>
I want the spec to have a section "events" which is a list of events that the spec instructs the user agent to fire in certain circumstances

[20:58:51.0000] <wycats>
define "have meaning to the element"?

[20:59:12.0000] <zewt>
elements don't do anything with events; they pass them on to on* attributes and that's it

[20:59:55.0000] <jamesr_>
there are default event handlers

[21:00:04.0000] <zewt>
those are part of the dispatcher, not the receiver

[21:00:11.0000] <jamesr_>
ah true

[21:00:53.0000] <jamesr_>
wycats: could you just look for things in the spec that invoke the 'dispatch an event…' algorithm?

[21:00:58.0000] <jamesr_>
probably could generate that with a script

[21:02:14.0000] <wycats>
jamesr_: that would depend on how judicious the spec-writer was about using precisely the right language in the right place in prose

[21:02:38.0000] <zewt>
fundamentally it doesn't seem good to spec this normatively because it would be redundant with the dispatch "side", which means redundant normative text (which is a big opportunity for specs to be self-contradicting)

[21:03:06.0000] <zewt>
wycats: if they're not doing that, they're probably also not going to keep these sorts of lists up to date either :)

[21:03:15.0000] <wycats>
zewt: can you describe to me how I could programmatically extract this information from the current spec?

[21:03:36.0000] <zewt>
you'd have to ask someone familiar with the spec's markup

[21:04:19.0000] <wycats>
zewt: to the best of my ability to read the spec, there isn't sufficient consistency in how event dispatching is described in prose to make your approach feasible

[21:04:35.0000] <zewt>
wycats: don't think that was me :)

[21:05:31.0000] <Hixie>
wycats: really now, you're citing the dev.w3.org copy? :-)

[21:06:16.0000] <wycats>
Hixie: oh noes

[21:06:46.0000] <Hixie>
wycats: (for the record, that copy is way out of date at this point, with numerous new errors beyond even the ones that are just ones i've fixed in the whatwg copy that they haven't taken yet)

[21:06:49.0000] <wycats>
Hixie: I stand by my original claim that the list of events that the spec instructs the user agent to fire directly on a particular event target is an important part of the interface of an event target

[21:06:58.0000] <Hixie>
wycats: i don't understand why

[21:07:09.0000] <wycats>
Hixie: that is very surprising to me

[21:08:23.0000] <Hixie>
wycats: wycats is it a more important part of the interface that the activation behaviour?

[21:08:38.0000] <zewt>
assuming you're talking normative text, what requirements would this place, exactly? "it must be possible for something, somewhere to fire each of the following events"?

[21:08:54.0000] <Hixie>
wycats: or than the content model?

[21:09:15.0000] <wycats>
Hixie: the content model is listed normatively at the top of every element

[21:09:16.0000] <Hixie>
wycats: or than the elements' meaning?

[21:09:20.0000] <zewt>
i mean, i might (unsure) agree if you were talking a non-normative "here are the things that are explicitly fired on this" note, but normatively I don't understand

[21:09:21.0000] <Hixie>
wycats: in prose

[21:09:29.0000] <Hixie>
wycats: same as what events fire

[21:09:31.0000] <wycats>
let's forget I asked about WebIDL for a second

[21:09:52.0000] <wycats>
there are lists of characteristics of elements in the spec

[21:10:09.0000] <wycats>
at the top of each element

[21:10:13.0000] <Hixie>
wycats: most of them (all, in a point of fact, other than the idl) in prose

[21:10:15.0000] <zewt>
events have no characteristics from the point of view of the element; the element knows nothing about them

[21:10:17.0000] <wycats>
some of those lists have information duplicated in the prose

[21:10:28.0000] <wycats>
http://www.whatwg.org/specs/web-apps/current-work/#the-a-element

[21:10:32.0000] <Hixie>
i don't think there's much duplication

[21:10:38.0000] <Hixie>
but maybe we have a different understanding of "in prose"

[21:10:40.0000] <wycats>
Do you consider the parts in the green box prose?

[21:10:48.0000] <Hixie>
all but the idl boxes, yes

[21:10:51.0000] <wycats>
I am suggesting adding it to the green box

[21:11:00.0000] <Hixie>
can you give an example of what it would say?

[21:11:04.0000] <Hixie>
say, for the <a> element?

[21:11:06.0000] <wycats>
I also think it belongs in the IDL box, but I will defer that discussion

[21:11:21.0000] <wycats>
Events:\nclick\netc.

[21:11:38.0000] <wycats>
possibly by pointing to some other part of the spec

[21:11:44.0000] <wycats>
similar to Global Attributes

[21:11:48.0000] <zewt>
that means every single element would include "click"

[21:11:49.0000] <wycats>
there could be Global Events

[21:11:56.0000] <wycats>
http://www.whatwg.org/specs/web-apps/current-work/#global-attributes

[21:12:03.0000] <wycats>
zewt: indeed it would

[21:12:08.0000] <zewt>
(well, rendering ones; obviously not <link>)

[21:12:33.0000] <wycats>
zewt: this kind of problem is already addressed for other things in the green box

[21:12:39.0000] <wycats>
Hixie: what should I call "things in the green box"?

[21:13:16.0000] <Hixie>
wycats: you just want a non-normative list of events that ...something, what, are mentioned in that section? for each element?

[21:13:28.0000] <zewt>
(can you clarify whether you're talking normative or non-normative?)

[21:13:30.0000] <Hixie>
wycats: "things in the green box"

[21:14:13.0000] <Hixie>
zewt: actually the HTML spec doesn't fire 'click' on most elements, that would be the (non-existent?) user-interface spec (exceptions for if the element has an activation behaviour), and here's no difference between <link> and <a> in that respect

[21:14:27.0000] <Hixie>
zewt: (you can click on a <link>, just make it display:block)

[21:14:30.0000] <wycats>
zewt: is the green box normative?

[21:14:41.0000] <Hixie>
parts of the green box are normative

[21:14:45.0000] <zewt>
wycats: hixie will tell me if i'm wrong, but unless it says "this box is non-normative" it is

[21:14:45.0000] <wycats>
which parts?

[21:14:55.0000] <wycats>
zewt: then I am talking about normative

[21:14:58.0000] <Hixie>
categories, content model, dom interface

[21:14:58.0000] <wycats>
a la the attributes

[21:15:27.0000] <Hixie>
i guess content attributes also, to a small extent

[21:15:29.0000] <wycats>
Hixie: Content attributes is non-normative?

[21:15:39.0000] <zewt>
normative is the parts that place requirements on things; non-normative (informative/notes) is stuff that doesn't (again modulo hixie :)

[21:15:39.0000] <Hixie>
(see http://www.whatwg.org/specs/web-apps/current-work/#element-definitions for a precise answer)

[21:15:47.0000] <wycats>
zewt: I am aware of the definition :P

[21:15:55.0000] <wycats>
Content attributes are duplicated in the prose below the green box

[21:15:57.0000] <zewt>
and i don't know what possible requirements this would be placing

[21:16:06.0000] <wycats>
if you eliminated the list of attributes, you could determine it by reading the prose

[21:16:09.0000] <wycats>
so why do we have a list?

[21:16:17.0000] <Hixie>
the "content attributes" normatively states which attributes MAY be specified, it's a conformance criteria just for authors/validators

[21:16:32.0000] <Hixie>
it's overridden for some attributes in the prose by MUST/MUST NOT be specified

[21:16:44.0000] <Hixie>
the definitions of the attributes of course aren't in the green box, they're all in prose

[21:16:49.0000] <Hixie>
later

[21:17:12.0000] <Hixie>
if we didn't have that list, we'd have to have it somewhere else saying "and you MAY have this attribute, and that attribute, and that one, and this one..."

[21:17:37.0000] <wycats>
Hixie: we already specify the definition of those attribtues

[21:17:39.0000] <wycats>
attributes

[21:17:43.0000] <Hixie>
?

[21:17:53.0000] <wycats>
the definition of href is in prose

[21:17:58.0000] <wycats>
so we don't also need it in a list

[21:18:08.0000] <Hixie>
the list doesn't have the definition, right

[21:18:09.0000] <wycats>
"If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor)."

[21:18:13.0000] <Hixie>
"it just has the MAY be specified"

[21:18:14.0000] <wycats>
Hixie: right

[21:18:25.0000] <Hixie>
what you just quoted is orthogonal, it's a requirement on browsers

[21:18:36.0000] <wycats>
Hixie: and the events would be "a user agent MAY fire this event on this event target"

[21:18:40.0000] <zewt>
(by the way, isn't "this list seems redundant, so another redundant list is okay too" an odd argument? :)

[21:18:41.0000] <Hixie>
(and authors, to the extent that authors are required to use elementsfor their meaning)

[21:18:47.0000] <Hixie>
wycats: woah! woah!

[21:18:52.0000] <Hixie>
wycats: that would be wildly wrong

[21:18:57.0000] <wycats>
would it?

[21:18:59.0000] <Hixie>
wycats: yes!

[21:19:03.0000] <wycats>
Hixie: say more

[21:19:06.0000] <Hixie>
wycats: browsers damn well better not randomly fire events!

[21:19:14.0000] <Hixie>
wycats: they MUST fire events exactly at specified times!

[21:19:18.0000] <Hixie>
wycats: that's not a MAY

[21:19:21.0000] <wycats>
Hixie: that's what the prose is form

[21:19:23.0000] <wycats>
for*

[21:19:27.0000] <wycats>
just like attributes

[21:19:28.0000] <Hixie>
wycats: ???

[21:19:31.0000] <Hixie>
this is nothing like attributes

[21:19:50.0000] <wycats>
ok

[21:19:53.0000] <wycats>
it's nothing like attributes

[21:20:26.0000] <wycats>
I would like a list of all of the events that the spec instructs the user agent to fire against an event target in some situation, and for them to be listed along with the specific event targets that they are specified to be fired on

[21:21:05.0000] <Hixie>
the spec instructs the user aget to fire every event against every EventTargets in some situation or other.

[21:21:17.0000] <Hixie>
(because of dispatchEvent, e.g.)

[21:21:56.0000] <wycats>
When I say "fire", I mean initialize and dispatch it to an event target

[21:22:03.0000] <wycats>
I do not mean the subsequent bubbling

[21:22:17.0000] <wycats>
"Note: Fire is short for initializing and dispatching an event."

[21:22:21.0000] <wycats>
that's what DOM4 says

[21:22:35.0000] <wycats>
"Note: Fire an event is a concept to make initializing and dispatching an event easier to write down."

[21:22:50.0000] <wycats>
from HTML: "In the contexts of events, the terms fire and dispatch are used as defined in the DOM Core specification"

[21:25:11.0000] <wycats>
so I am asking for a list of event types that the user agent is instructed to initialize and dispatch to an element in some circumstance

[21:25:19.0000] <zewt>
(event.dispatchEvent() uses the term "dispatch" to fire an arbitrary, user-created event)

[21:26:07.0000] <wycats>
zewt: I am excepting user-created events from my request

[21:26:23.0000] <wycats>
I mean event names that the specification explicitly defines

[21:27:51.0000] <Hixie>
well you can just click on the word "dispatch" in the HTML spec and it'll give you that answer

[21:28:07.0000] <Hixie>
hm, i guess not

[21:28:12.0000] <Hixie>
i haven't cross-referenced it enough

[21:28:19.0000] <zewt>
Hixie: there aren't many yeah

[21:28:25.0000] <Hixie>
ok then search for the words "fire" and "dispatch" :-)

[21:28:44.0000] <zewt>
that would probably be a big enough list to make the xref popup unhappy :)

[21:28:46.0000] <Hixie>
hm, searching for "fire" brings up the "firefox" in each status box

[21:28:49.0000] <Hixie>
that sucks

[21:28:59.0000] <zewt>
(i use "fire ")

[21:29:05.0000] <Hixie>
oh that works

[21:30:05.0000] <zewt>
"fire a simple event" at least seems pretty consistently xref'd

[21:30:20.0000] <Hixie>
yeah, that existed and meant something specific before dom core existed

[21:30:21.0000] <zewt>
(that one predates dom4, right?)

[21:31:53.0000] <Hixie>
searching for dispatch isn't so hot

[21:32:57.0000] <zewt>
seems like the only major false positive is "track dispatch type"

[21:34:43.0000] <zewt>
afk

[21:34:43.0000] <Hixie>
wycats: anyway, i don't really see what such a list would bring to the table. it's redundant with the text, and would always be getting out of date

[21:36:05.0000] <wycats>
Hixie: again, that is surprising to me

[21:36:27.0000] <wycats>
but I am not the intended consumer of the spec

[21:36:30.0000] <wycats>
so

[21:36:32.0000] <wycats>
seems good bros

[21:37:50.0000] <Hixie>
wait, you're asking for something you don't actually even want? :-)

[21:44:33.0000] <wycats>
I absolutely want it

[21:44:49.0000] <wycats>
and I think it would be extremely valuable to "author" consumers of the spec

[21:47:20.0000] <wycats>
let's try an experiment:

[21:47:22.0000] <wycats>
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-video-element

[21:47:27.0000] <wycats>
I am an "author"

[21:47:35.0000] <wycats>
I would like to learn the interface for interacting with the video tag

[21:47:53.0000] <wycats>
how does one go about doing this?

[21:48:01.0000] <Hixie>
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mediaevents

[21:48:06.0000] <Hixie>
next :-)

[21:49:22.0000] <Hixie>
(keeps going out of sync with the normative parts of the spec and is a pain in the ass to maintain, but for <video> it's probably worth it)

[21:53:53.0000] <wycats>
do you not consider it a problem that the event list is not together with the element?

[21:53:59.0000] <wycats>
I didn't ask you to link me to the event list

[21:54:15.0000] <Hixie>
how do you mean it's not together with the element? it's right there in the element's section!

[21:54:16.0000] <wycats>
I asked you to tell me how someone who goes to the video tag in the multipage spec can figure it out

[21:54:33.0000] <wycats>
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-video-element

[21:54:36.0000] <wycats>
scroll down

[21:54:36.0000] <Hixie>
(well, media elements section)

[21:54:41.0000] <wycats>
until you read "the audio element"

[21:54:42.0000] <wycats>
yes!

[21:54:50.0000] <smaug____>
Hixie: I was very surprised that you decided to change MutionObserver handling in the spec

[21:54:57.0000] <smaug____>
there are no technical reasons for it

[21:55:06.0000] <wycats>
why isn't it referenced from the element?

[21:55:43.0000] <Hixie>
smaug____: it wasn't my intention to change it, i just had forgotten to update the spec to say "mutation events and observers" everywhere. but i don't really have a strong opinion either way, i'll just do what the browser vendors want to implement. i kinda assumed it'd be costly to have to track every single insertion in parsing a document.

[21:56:16.0000] <Hixie>
wycats: the video and audio elements are basically the same, and their processing model is tightly integrated with the source and track elements', so all four are defined in one section, "media elements", to which each of those sections links.

[21:56:28.0000] <smaug____>
you don't need to track every insertion unless you have mutation observers

[21:56:38.0000] <Hixie>
smaug____: it's at least a branch for each insertion

[21:56:44.0000] <smaug____>
and mutation observer are anyway *a lot* cheaper than mutation events

[21:56:56.0000] <Hixie>
smaug____: if you're trying to convince me there is no need :-)

[21:56:58.0000] <smaug____>
Hixie: so?

[21:57:11.0000] <smaug____>
in code there are many branches :)

[21:57:14.0000] <Hixie>
smaug____: like i said, i'm happy to do whatever browsers want to implement

[21:57:21.0000] <smaug____>
we decide to either implement some feature or not

[21:58:06.0000] <smaug____>
Hixie: so, Gecko is happy to implement MutationObserving during parsing

[21:58:14.0000] <smaug____>
and not happy to not have it

[21:58:36.0000] <Hixie>
smaug____: so i saw from jonas' e-mail earlier tonight

[21:59:11.0000] <Hixie>
smaug____: hopefully you are not in the minority, and it becomes a non-issue and i just update the spec

[21:59:33.0000] <Hixie>
wycats: (where would you put that table otherwise?)

[22:00:01.0000] <smaug____>
I believe, could be wrong here, that this is just a case a bit tricky to implement in webkit, so they don't want mutation observers during parsing

[22:00:08.0000] <wycats>
Hixie: I think it should be linked off of the green box

[22:00:19.0000] <wycats>
in a section called Events, with the name Media Events

[22:01:07.0000] <Hixie>
smaug____: get opera or microsoft to weigh in on your side then :-) (didn't the chrome guys say they had done this already?)

[22:01:38.0000] <smaug____>
/me hates these fights about API sanity

[22:01:58.0000] <Hixie>
smaug____: you should probably not be involved in web standards work then, that's all we do :-)

[22:02:19.0000] <smaug____>
Hixie: but until this is clear, the spec shouldn't say anything about it

[22:02:22.0000] <Hixie>
wycats: i think if we had a table like this for every object and element it might make sense to have a place to link to it from in the green box, but this is simply not that common in practice (because for most elements there's zero or close to zero relevant events)

[22:02:42.0000] <smaug____>
or say that this is still unclear

[22:03:10.0000] <Hixie>
smaug____: if it's really 50/50 then yeah, i add one of those warnings that says "thar be dragons"

[22:03:18.0000] <Hixie>
smaug____: like with the video mime type handling

[22:03:46.0000] <Hixie>
smaug____: i'd need to speak to the opera, webkit, and IE guys first to work out where the chips actually lie

[22:04:10.0000] <smaug____>
yes, after that you could say something in the spec

[22:04:20.0000] <smaug____>
but please don't take your side before that

[22:07:02.0000] <smaug____>
/me should learn... keep the APIs in separate specs so that you can control them yourself :)

[22:07:02.0000] <Hixie>
i don't have a side

[22:07:11.0000] <Hixie>
i really couldn't care less about this :-)

[22:07:27.0000] <wycats>
what is the controversy anyway?

[22:07:35.0000] <Hixie>
there is no controversy

[22:07:52.0000] <Hixie>
anyway, afk for a bit

[22:07:53.0000] <smaug____>
Hixie: you decided to add something to the spec, so you do have some opinion, or decided for some reason to follow what webkit devs want, but not what gecko devs want

[22:08:05.0000] <smaug____>
you could just leave the whole thing out from the spec for now

[22:08:08.0000] <Hixie>
smaug____: i just followed what the spec said already

[22:08:18.0000] <smaug____>
no

[22:08:22.0000] <Hixie>
get the other browsers to say something and i'll fix it tomorrow

[22:08:25.0000] <Hixie>
sheesh, relax dude

[22:08:27.0000] <smaug____>
MutationObserver is totally different thing to Mutation Events

[22:10:20.0000] <smaug____>
yeah, I could relax :) , but when random stuff ends up to the specs, there is something to fix

[22:17:37.0000] <zewt>
heh, messing around with setting a <script>'s display to block, hit a firefox bug almost immediately

[22:17:46.0000] <zewt>
in the list of Bugs That Nobody Cares About

[22:18:16.0000] <zewt>
(<script style="display: block;">foo();</script> doesn't show up by itself, but stick some text before it and it does)

[22:18:49.0000] <zewt>
hmm

[22:19:03.0000] <zewt>
maybe just really weird but intentional rendering behavior? since chrome does it, too

[22:19:21.0000] <zewt>
(not that I really care, either, just messing about)

[22:20:11.0000] <zewt>
or maybe something to do with implicit <head>/<body>

[22:21:00.0000] <zewt>
yeah, guess so (stick <link> before it and it doesn't show up; stick <div> and it does)

[22:21:16.0000] <zewt>
anyway, off to bed

[00:17:25.0000] <annevk>
oh god

[00:17:34.0000] <annevk>
someone respec'd DOM Parsing

[00:36:01.0000] <Ms2ger>
zewt, yep, your script was in the head, and head has display: none as well

[00:36:12.0000] <zcorpan>
Hixie: knowing that there aren't any relevant events fired on the element is useful to know for authors (just like with attributes)

[00:36:57.0000] <zcorpan>
Hixie: i agree with wycats that it would be useful for authors with non-normative information about events for each element (like the table for media elements)

[00:38:37.0000] <zcorpan>
for most of the spec, it has to be gathered by reading the UA requirements, which is not so nice for authors (and will even be omitted completely from the developers.whatwg.org version)

[00:48:24.0000] <zcorpan>
zewt: if you had tested in live dom viewer you would see where the script element lived in the dom :-)

[00:53:12.0000] <Ms2ger>
Hixie, you called after 2AM my time?

[01:00:56.0000] <annevk>
yeah, wycats had a good point, too bad it was badly misunderstood :/

[01:21:42.0000] <jgraham>
OTOH Hixie has a point that increasing the amount of non-normative text leads to more things that can go out of sync

[01:27:47.0000] <zcorpan>
sure

[01:29:44.0000] <annevk>
is there any other info you'd want to know about an object that's not evident from IDL?

[01:46:11.0000] <zcorpan>
omission of tags maybe

[01:46:19.0000] <zcorpan>
but that's kinda complicated

[01:47:35.0000] <zcorpan>
Start tag: sometimes optional (with link to the right place in the syntax section)

[01:55:35.0000] <annevk>
that's element-specific

[01:55:45.0000] <annevk>
I was wondering about stuff like Node / XMLHttpRequest

[01:55:58.0000] <annevk>
but yeah, start/end tag stuff would be nice to have hints about

[02:04:17.0000] <jgraham>
Start/end tag stuff is unneeded complexity if the goal is to help authors

[02:04:55.0000] <zcorpan>
jgraham: yeah probably

[04:23:06.0000] <annevk>
https://twitter.com/andydavies/status/241117462068879360 euh, he realizes what those pages render in right?

[04:23:11.0000] <annevk>
oh well

[04:23:22.0000] <annevk>
see you guys next week

[04:25:15.0000] <Ms2ger>
Gone again?

[04:25:39.0000] <annevk>
just a few days

[04:25:42.0000] <annevk>
should be back Sunday night

[04:25:43.0000] <jgraham>
I presume he is going to ride the trains with the other hobos

[04:25:49.0000] <jgraham>
:)

[04:26:03.0000] <annevk>
dude, unemployed != hobo

[04:26:38.0000] <Ms2ger>
Rich hobo?

[04:26:42.0000] <jgraham>
"Unlike 'tramps', who work only when they are forced to, and 'bums', who do not work at all, 'hobos' are workers who wander"

[04:27:01.0000] <jgraham>
Is the WikiTruth

[04:27:24.0000] <jgraham>
Are you claiming that 'bum' would have been more accurate?

[04:29:02.0000] <jgraham>
(the more Wikipedia I read teh more I think my original usage is a good fit, although it wasn't intended in seriousness)

[04:34:40.0000] <zcorpan>
jgraham: edit wikipedia to say "One example of a hobo is Anne van Kesteren."

[04:35:52.0000] <Ms2ger>
/me whacks zcorpan with a banhammer

[04:36:19.0000] <jgraham>
Ms2ger: Is that like a cross between a hammaer and a banana?

[04:36:30.0000] <jgraham>
*hammer

[04:36:55.0000] <Ms2ger>
It's a hammer with a banana attached

[04:36:58.0000] <zcorpan>
Ms2ger: doesn't help much if jgraham makes the edit :-P

[04:38:21.0000] <annevk>
jgraham: can they have a home?

[06:45:28.0000] <zewt>
zcorpan: there are lots of ways to test the same thing :)

[06:47:13.0000] <zcorpan>
zewt: hmm?

[06:49:33.0000] <jgraham>
zcorpan: I can only imagine he is talking about the "you should have used the live dom viewer thing"

[06:50:18.0000] <jgraham>
s/ thing"/" thing/

[07:24:47.0000] <Hixie>
Ms2ger: yt?

[07:24:51.0000] <Hixie>
Ms2ger: what's the doal with dom parsing?

[07:50:26.0000] <jgraham>
Hixie: How does the spec ensure that <script defer src> is run before DOMContentLoaded?

[07:51:17.0000] <jgraham>
Oh, sorry defer

[07:51:35.0000] <jgraham>
Wrong set|list of scripts

[07:52:19.0000] <Hixie>
yeah this part of the spec is absurdly complicated

[07:52:31.0000] <Hixie>
much like the rest of the parser and script processing

[07:52:38.0000] <Hixie>
or like <object> processing

[07:54:02.0000] <Ms2ger>
Hixie, Microsoft has forked parsing

[07:54:13.0000] <Hixie>
Ms2ger: so you're still editing your canonical version?

[07:54:15.0000] <Ms2ger>
I don't know if anyone else intends to pay attention to them

[07:54:17.0000] <Ms2ger>
Yeah

[07:54:19.0000] <Hixie>
phew

[07:55:06.0000] <jgraham>
Hixie: I'm pretty sure that navigation is more confusing than anything

[07:55:13.0000] <Hixie>
jgraham: hear hear

[07:55:28.0000] <Hixie>
Ms2ger: sounds like you may want to have mike create a component in the WHATWG product in bugzilla, and then move all the bugs over

[07:56:13.0000] <MikeSmith>
yeah I can do that

[07:56:19.0000] <Ms2ger>
Sounds good

[07:56:32.0000] <MikeSmith>
remind me later if I forget

[07:56:43.0000] <MikeSmith>
I have two hours of telcons starting right now

[07:57:04.0000] <Hixie>
sweet lord

[07:58:26.0000] <jgraham>
Ohh, I know this feeling. It's schadenfreude.

[07:58:32.0000] <jgraham>
/me laughs at MikeSmith 

[07:58:40.0000] <MikeSmith>
hah

[08:27:52.0000] <Hixie>
/me has no idea what before() and after() do

[08:33:35.0000] <jgraham>
Hixie: How can you edit the HTML5 spec if you aren't spending half your time learning jQuery / backbone / modernizr / responsive design hacks / other trend de-jour?

[08:37:07.0000] <jgraham>
(since this is the internet I made a useful sign: [ SARCASM ] )

[08:48:29.0000] <darobin>
/me sets his watch by dglazkov's greeting

[08:49:49.0000] <dglazkov>
:)

[08:52:58.0000] <Hixie>
jgraham: i am spending half my time (well, ok, maybe less than half) writing web apps (mainly games), but in doing so i haven't found much of a need for libraries.

[08:53:07.0000] <Hixie>
Ms2ger: :-P

[08:54:57.0000] <Hixie>
wasn't it mozilla that convinced me to make defer not apply to inline scripts in the first place?

[08:58:17.0000] <jgraham>
Uh, so async on inline scripts… that sounds like it would be remarkably similar to today (until modules)

[09:02:59.0000] <Ms2ger>
Hixie, that would probably be hsivonen, not mozilla ;)

[09:08:18.0000] <jgraham>
I thought it was usually Microsoft that did the referring-to-people-by-their-company thing

[09:11:34.0000] <hober>
Ms2ger: have you talked to travis about working together on the dom parsing spec? ideally the dvcs.w3.org one would be the same as yours

[09:12:43.0000] <Ms2ger>
hober, he does not appear to be interested to do that

[09:13:56.0000] <hober>
:(

[09:14:49.0000] <Ms2ger>
I'm glad that Microsoft has come out in support of forking, though

[09:16:16.0000] <hober>
hahahahaa. unidirectional forking maybe.

[09:17:02.0000] <Ms2ger>
Is that a nice word for "hypocrisy"?

[09:17:04.0000] <TabAtkins>
Hixie: el1.before(el2) inserts el2 into the document immediately before el1.

[09:21:05.0000] <jgraham>
Which is all kinds of wrong since it leaves el2 before el1

[09:22:19.0000] <TabAtkins>
...yes?  There's the inverse, insertBefore(), if you want the other behavior.

[09:22:38.0000] <TabAtkins>
Depends on whether you're currently chaining with the element you want to insert, or the one you want to insert something around.

[09:23:28.0000] <jgraham>
I'm just saying that, ignoring the fact that "before" isn't a verb, it reads as the opposite of what it does

[09:23:44.0000] <TabAtkins>
Sure.  Warping grammar to pl concepts is a hard problem.

[09:24:22.0000] <TabAtkins>
You quickly learn that before and insertBefore are identical save for the target/arg switch, and insertBefore is obviously more of a command to insert the target before the arg, so before must be the opposite.

[09:25:13.0000] <Ms2ger>
https://twitter.com/sgalineau/status/241152263119327232

[09:27:23.0000] <TabAtkins>
Ms2ger: Was just reading http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-node and noted that the nodeValue and textContent attributes looks misaligned.  They're not (the extra space is because they're not readonly), but could you sort them so all the attributes are together?

[09:27:24.0000] <jgraham>
I still find it hard to remember the right argument order for insertBefore, so that hardly seems like a point in its favour

[09:27:37.0000] <TabAtkins>
jgraham: Well then you're just hopeless. ^_^

[09:28:23.0000] <Ms2ger>
That seems like a strange way to sort :)

[09:28:39.0000] <TabAtkins>
Ms2ger: How are they sorted currently?

[09:28:52.0000] <Ms2ger>
Sorta topical

[09:29:34.0000] <Ms2ger>
/me wonders how cloneNode and isEqualNode ended up grouped together

[09:30:13.0000] <jgraham>
"weird cousins that no one likes"?

[09:30:20.0000] <TabAtkins>
Emphasis on the "sorta". ^_^  At least, could you move the compareDocumentPosition bits to below the following sections?  nodeValue and textContent are more like childNodes than an iterator.

[09:30:55.0000] <TabAtkins>
There's also a double blank line after normalize, which seems odd.

[09:31:13.0000] <Ms2ger>
Yeah

[09:31:31.0000] <Ms2ger>
/me had better learn to use hg-git, then

[09:31:44.0000] <jgraham>
Or, you know, git

[09:32:29.0000] <Ms2ger>
Nah, I tried that

[09:33:24.0000] <TabAtkins>
Where is it stored?  It looks like dvcs.w3.org, which would just be normal hg.

[09:33:35.0000] <Ms2ger>
https://github.com/whatwg/dom

[09:33:49.0000] <TabAtkins>
Ah, interesting.

[09:34:00.0000] <TabAtkins>
I can just pull-request you, if you'd like.

[09:34:17.0000] <Ms2ger>
Nah, I need to figure it out anyway

[09:34:28.0000] <Ms2ger>
This is as good a time as any :)

[09:35:08.0000] <JonathanNeal>
hello

[10:25:14.0000] <paul_irish>
jgraham: since over half the web uses jQuery because DOM methods are verbose and uncomfortable it seems odd to discard its influence on web development so trivially.

[10:25:47.0000] <paul_irish>
basically all the hacks and libraries you list are created because the platform isn't good enough for developers to use directly

[10:26:43.0000] <paul_irish>
So... to ignore the way developers choose to interact with the platform seems to be at odds at delivering a platform developers can make good use of.

[10:28:30.0000] <Hixie>
there were some proposals made for function names that were short yet still clear, which seems like a win

[10:29:04.0000] <paul_irish>
definitely :)

[10:31:48.0000] <Hixie>
paul_irish: (the problem with just making new APIs match the style of the library-du-jour is that it leads to the platform having multiple personality disorder with different parts having different styles)

[10:32:07.0000] <Hixie>
paul_irish: (better IMHO to try to make the platform consistent with itself, while still learning from past mistakes like not having ultraverbose method names)

[10:32:50.0000] <Hixie>
paul_irish: (that way at least it has a single style, and then people can layer libraries over that if they want a different style, rather than people having to learn multiple styles to use the web without a library, and being forced ot use a library to paper over hte parts that have the styles they don't like)

[10:33:07.0000] <Hixie>
paul_irish: (still, we should obviously not _ignore_ the libraries)

[10:33:30.0000] <paul_irish>
That seems fair, though I don't know how sold I am on the value of consistency with DOM's legacy...

[10:33:44.0000] <Hixie>
well, consistency is relative

[10:33:50.0000] <paul_irish>
aye.

[10:33:54.0000] <paul_irish>
but yeah my larger point is that these are not du-jour libraries

[10:34:13.0000] <Hixie>
on the timescale of the web (dozens if not hundreds of years), the entire _web_ is "du jour"

[10:34:14.0000] <paul_irish>
du-decade :)

[11:21:13.0000] <scott_gonzalez>
Hixie: Regarding :enabled and :disabled, there was a bug filed for this as well https://www.w3.org/Bugs/Public/show_bug.cgi?id=18628

[11:22:28.0000] <Hixie>
thanks for the heads-up

[11:22:31.0000] <Hixie>
will resolve the bug

[11:48:11.0000] <tantek>
Hixie, paul_irish, or eventually a single library becomes dominant enough to effectively become part of the platform, and it's at least even odds as to whether that's happening with jQuery.

[11:48:46.0000] <tantek>
/me waits for a jQuery Community Group to emerge.

[11:58:46.0000] <Hixie>
heycam|away: if i have a function in web idl overloaded like so: void f(DOMString s); void f(Callback c);  where Callback is  callback Callback = any ();

[11:59:19.0000] <Hixie>
heycam|away: is there any value that can be passed to f() that won't either be treated as a DOMString or a Callback?

[11:59:41.0000] <Hixie>
heycam|away: (and thus by extension, is there any way for [TreatNonCallableAsNull] to have an effect on Callback, or would it be completely redundant there?)

[12:00:52.0000] <Ms2ger>
Correct

[12:01:57.0000] <Hixie>
i didn't make any statements, how can my questions be correct :-P

[12:02:12.0000] <Ms2ger>
No / redundant

[12:02:20.0000] <Ms2ger>
You asked good questions!

[12:02:31.0000] <Hixie>
k :-)

[12:04:45.0000] <Hixie>
is there ever a case where the fragment algorithm is invoked without a context, these days?

[12:05:44.0000] <Ms2ger>
Was there ever one?

[12:06:03.0000] <Hixie>
document.innerHTML

[12:06:17.0000] <Ms2ger>
Oh

[12:06:22.0000] <Ms2ger>
Then probably not

[12:08:30.0000] <Hixie>
anyone understand https://www.w3.org/Bugs/Public/show_bug.cgi?id=17935 ?

[12:08:40.0000] <Hixie>
even assuming they mean ImageData rather than ImageInfo, I'm still at a loss

[12:10:10.0000] <Ms2ger>
I think they want to draw the pixels in the ImageData somewhere

[12:10:27.0000] <jgraham>
paul_irish: I made two seperate points, neither of which is

[12:12:10.0000] <jgraham>
"we should ignore libraries". One was the suggestion (which I have seen) that Hixie is not qualified to edit the spec because he is not always using the latest frameworks/libraries/fashioanble things/ is absurd. The other is that particular names that have been proposed for the DOM API are horrible, even though they match jQuery

[12:13:23.0000] <Ms2ger>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0292.html

[12:13:32.0000] <Ms2ger>
But mailing lists are support forums!

[12:14:43.0000] <Hixie>
/me bops Ms2ger on the head with a flip flop

[12:14:56.0000] <Ms2ger>
:)

[12:15:34.0000] <Hixie>
why can't people who file bugs like https://www.w3.org/Bugs/Public/show_bug.cgi?id=15919 actually DO THE TESTING rather than asking ME to do it

[12:15:50.0000] <Hixie>
who does that guy think i am anyway

[12:16:44.0000] <Velmont>
The sole web platform QA :D

[12:17:53.0000] <jgraham>
You mean soul web platform QA, right?

[12:18:12.0000] <Ms2ger>
Hixie, well played

[12:18:31.0000] <jgraham>
That's why he gets a little R.E.S.P.E.C.T

[12:19:13.0000] <jgraham>
Hixie: I wonder if I wrote tests for that yet. I ought to have done but might well have not thought of that case

[12:19:37.0000] <Hixie>
jgraham: yeah, same here

[12:19:56.0000] <Hixie>
jgraham: (well, except obviously i did think of the case at some point)

[12:20:08.0000] <Hixie>
lunch first

[12:22:28.0000] <GrenBaykre>
So...

[12:22:37.0000] <GrenBaykre>
Are you folks responsible for WebGL?

[12:22:56.0000] <Ms2ger>
Unfortunately not

[12:23:01.0000] <Velmont>
Nah, Khronos thingy.

[12:23:28.0000] <GrenBaykre>
Well...

[12:23:38.0000] <GrenBaykre>
IE current doesn't even support WebGL at all.

[12:23:43.0000] <GrenBaykre>
That's a big-ass problem for me.

[12:23:53.0000] <GrenBaykre>
I need to be able to draw 3D stuff.

[12:24:00.0000] <GrenBaykre>
(Game/interactive art.)

[12:24:27.0000] <Velmont>
We're mostly Operaians, Mozillians and Googlefolks here though, of vendors. At least the ones that make the most noise.

[12:24:42.0000] <Velmont>
All of which have WebGL.

[12:24:53.0000] <GrenBaykre>
I am an Operian, but nobody gives a shit about what I am.

[12:24:58.0000] <GrenBaykre>
People use IE and other junk.

[12:25:14.0000] <Sidnicious>
:)

[12:25:21.0000] <Sidnicious>
GrenBaykre: Have you looked at stuff like https://github.com/mrdoob/three.js/ ?

[12:25:32.0000] <GrenBaykre>
Yes, I have tried to understand Three.js.

[12:25:41.0000] <GrenBaykre>
I have a number of questions which I find hard to articulate regarding it, though.

[12:26:24.0000] <GrenBaykre>
It appears to just be a framework/wrapper around, in theory, various "engines" to display the 3D stuff in a browser.

[12:26:39.0000] <GrenBaykre>
BUT all the examples I've seen of it using non-WebGL have looked like crap and been very slow.

[12:27:22.0000] <Velmont>
Well, if you really care that much about IE right now, then you can write 2d canvas for it.

[12:27:50.0000] <Velmont>
Erik Möller in Opera ported his game to both WebGL and 2D canvas, you can switch between them at runtime.

[12:28:10.0000] <Sidnicious>
GrenBaykre: Just poking through their change log, ran into this guy: http://iewebgl.com/Default.aspx

[12:30:01.0000] <GrenBaykre>
I don't know what you meant by that, Velmont.

[12:30:18.0000] <GrenBaykre>
Sidnicious: Oh... an evil, crazy hack!

[12:30:24.0000] <GrenBaykre>
Sidnicious: Those kinds of things really amaze me.

[12:30:36.0000] <GrenBaykre>
I think there was a "SVG inside Flash" for IE as well... hehe.

[12:30:51.0000] <Sidnicious>
heh

[12:31:06.0000] <GrenBaykre>
"IEWebGL is a plugin for Microsoft Internet Explorer web browser" <-- If it's an actual plug-in, that is virtually worthless, I'm afraid.

[12:31:11.0000] <GrenBaykre>
Because users won't install that.

[12:31:15.0000] <jgraham>
GrenBaykre: You have two basic choices: 1) Use WebGL get hardward acceleration. Don't support IE users and the large set of people without the right hardware for WebGL. 2) Don't do something that needs WebGL.

[12:31:18.0000] <GrenBaykre>
But if it's a .js and maybe a .swf...

[12:31:29.0000] <Sidnicious>
yeah, I got the impression it was an actual plugin too

[12:31:34.0000] <GrenBaykre>
Well, I need to do 3D stuff. I've prolonged it for a decade or more.

[12:32:36.0000] <jgraham>
If that means "hardware accelerated 3D" then there is currently no solution that will work for a majority of users

[12:32:58.0000] <jgraham>
IE users are only a subset of those that will be excluded

[12:33:29.0000] <GrenBaykre>
Well, actually, my 3D needs are (at least initially) extremely primitive, almost to compare with non-textured/wireframe things.

[12:33:43.0000] <GrenBaykre>
But all the 3D tests in Canvas have apparently been crap.

[12:33:45.0000] <Sidnicious>
I think Velmont meant that it would, technically, be possible to write your stuff for WebGL and also to draw on a <canvas>, and use whatever's available

[12:33:56.0000] <GrenBaykre>
Not sure what they mean by SVG as an engine, though.

[12:34:08.0000] <Velmont>
Sidnicious: No, -- you can write a rendering backend that can render to webgl or to 2d canvas. :-)

[12:35:59.0000] <hober>
Velmont: there are plenty of apple people here too

[12:36:25.0000] <GrenBaykre>
Hrm...

[12:37:15.0000] <Velmont>
hober: Oh, yeah, you make a lot of noise too :] Although I didn't forgot connecting you to Safari.

[12:37:55.0000] <hober>
:)

[12:38:26.0000] <Velmont>
uh, s/didn't//

[12:51:13.0000] <Sidnicious>
Before I forget, I was wondering: why are XMLHTTPRequests specced to only use multipart/form-data when they're sent with FormData?

[12:54:13.0000] <jgraham>
Sidnicious: I don't know, but what's your use case for something different?

[12:55:01.0000] <GrenBaykre>
http://www.apple.com/safari/ <-- No trace of Safari for Windows anymore.

[12:55:07.0000] <GrenBaykre>
So I guess that version is gone

[12:55:21.0000] <GrenBaykre>
"Only" IE, Firefux, Chrome and Opera to worry about.

[12:56:20.0000] <MikeSmith>
Hixie, zcorpan, remind me to remind Ms2ger that I made a component for DOM Parsing spec https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWG&component=DOM%20Parsing%20and%20Serialization&resolution=---

[12:56:25.0000] <Sidnicious>
Shh, they can hear you when you call it that around here.

[12:58:33.0000] <Sidnicious>
jgraham: I don't have a great one, except that urlencoded is more compact and more widely-supported. The only reason I noticed is that, it turns out, our web framework goes down a "hey, let's expect a file upload" path when it sees a multipart form and 403s the request if a file upload isn't allowed at that URL.

[12:59:02.0000] <Sidnicious>
(that's definitely a bug on our end, it just made me curious)

[13:01:14.0000] <Sidnicious>
Since, if the form were sent normally, the UA ordinarily uses urlencoded when a file isn't involved.

[13:04:39.0000] <jgraham>
MikeSmith: Now I feel left out not to be in your trusted group of reminders :p

[13:06:54.0000] <jgraham>
TabAtkins: I think your barcode inputmode argument would benefit from an example of how the UI might work if the UA wanted to allow barcode input to any input type but still make use of a special attribute

[13:14:39.0000] <MikeSmith>
jgraham: I just wasn't sure you weren't away

[13:14:56.0000] <MikeSmith>
you seem to keep more reasonable hours than zcorpan

[13:15:28.0000] <Velmont>
I plan on snatching the whole reminding thing away from that trusted tight-knit group by being the reminder! Mohaw!111

[13:31:29.0000] <jgraham>
MikeSmith: zcorpan does early mornings, which I don't, but I'm not sure about evenings

[13:32:00.0000] <MikeSmith>
OK

[13:34:14.0000] <jgraham>
Stats say I am never here 3am - 8am (if I got the timeoffset right, maybe I didn't?), but zcorpan sometimes is

[14:49:56.0000] <Subcide>
Hey guys, are there any known problems with the unsubscribe function on the mailing list that anyone's aware of?  I'm completely unable to unsubscribe at the moment.

[14:55:36.0000] <Hixie>
Subcide: should be working... can you walk me through what you're doing and what it did?

[14:58:26.0000] <Subcide>
Entered my email address on http://lists.whatwg.org/options.cgi/implementors-whatwg.org and clicked unsubscribe.  It says an email confirmation will be sent, but I never receive it.

[14:58:53.0000] <Subcide>
Checked every possible trash, junk, etc.

[14:59:02.0000] <Subcide>
Password reminders don't get to me either.

[15:01:28.0000] <Hixie>
what list are you trying to unsubscribe from?

[15:01:55.0000] <Hixie>
and what e-mail address are you subscribed with?

[15:02:45.0000] <Subcide>
Damnit, was on the wrong list page.

[15:03:19.0000] <Subcide>
System probably shouldn't say it's sent an email when the address is invalid for a list ;)

[15:04:09.0000] <Hixie>
that'll do it :-)

[15:04:38.0000] <Subcide>
Thanks :)

[15:05:26.0000] <gsnedders>
Asking someone for help oftens helps you realize you're being silly. :)

[15:06:02.0000] <Subcide>
As a designer, I blame poor UX ;)

[15:06:32.0000] <gsnedders>
I do this with doors frequently. I want to know whether to push or pull the door1

[15:06:35.0000] <gsnedders>
*!

[15:08:11.0000] <Subcide>
One day, when Apple make doors, they'll make sense.  And only need to be replaced every 3 years or so.

[15:18:32.0000] <Philip`>
They should avoid the push/pull problem by making circular doors which you spin anticlockwise to open and clockwise to close

[15:38:33.0000] <zewt>
(then they'll sue everyone else who makes doors)

[16:11:07.0000] <Hixie>
jesus wept, there is _no_ interop here

[16:15:12.0000] <gsnedders>
Pretty certain that's too long to be the shortest verse in the Bible.

[16:18:40.0000] <Hixie>
looks like opera doesn't fire onunload during document.open(), and if you call document.open() in unload, it essentially cancels the unload

[16:19:15.0000] <gsnedders>
We basically never fire unload.

[16:20:23.0000] <gsnedders>
Basically, count yourself lucky if you ever get an unload event. :)

[16:20:43.0000] <Hixie>
firefox just ignores document.open() and document.write() in unload, and doesn't fire onunload for document.open()

[16:22:48.0000] <Hixie>
chrome doesn't fire onunload during document.open(), but allows document.open() during onunload, though it doesn't cancel the unload

[16:22:54.0000] <Hixie>
(so you can't see it)

[16:23:10.0000] <Hixie>
(except in logs)

[16:23:39.0000] <Hixie>
safari matches chrome

[16:23:46.0000] <Hixie>
anyone got IE handy?

[16:29:26.0000] <Hixie>
interesting. chrome _does_ fire onunload for nested iframes during document.open().

[16:29:47.0000] <Hixie>
firefox too

[16:30:23.0000] <Hixie>
(not opera, but that fits gsnedders' point)

[16:31:04.0000] <Hixie>
safari does too

[16:42:11.0000] <Hixie>
so i guess the simplest solution here is to make the spec not fire unload events at documents that are currently executing document.open()

[16:45:15.0000] <Hixie>
chrome doesn't fire beforeunload at all, it seems, in document.open

[16:46:18.0000] <Hixie>
opera doesn't seem to fire it at all (?)

[16:47:20.0000] <Hixie>
safari's the same as chrome

[16:47:56.0000] <Hixie>
firefox fires it, though seems to ignore the result (?)

[16:48:47.0000] <Hixie>
and doesn't seem to fire it for any frames, nested or otherwise, if the outer frame calls document.open() during beforeunload...

[16:49:23.0000] <Hixie>
damnit, i really need to test ie here

[16:58:26.0000] <Hixie>
ok... IE does run beforeunload, but doesn't fire it for subframes... similar to Firefox... but if you cancel it, the previous (outer) document.open() has no effect, it seems

[16:58:58.0000] <Hixie>
but if you don't cancel it, it doesn't do anything at all?

[16:58:59.0000] <Hixie>
wtf

[16:59:26.0000] <Hixie>
it does fire unload for the nested frame

[16:59:40.0000] <Hixie>
but not the outer frame


2012-08-31
[17:24:05.0000] <TabAtkins>
jgraham: inputmodes are generally just meant for soft keyboards, no?  So it would work like the other examples - it would have a barcode button on whatever keyboard it normally pops up.

[17:31:18.0000] <Hixie>
TabAtkins: are there examples of OSes that support doing that?

[17:32:12.0000] <TabAtkins>
Not that I know of.

[17:32:25.0000] <TabAtkins>
(Because no mobile OS has a built-in barcode reader, I think.)

[17:32:49.0000] <TabAtkins>
/me leaves now.

[17:56:11.0000] <Hixie>
i think taking out the onbeforeunload for document.open() probably makes sense too, given the difficulty in working out what it even means

[19:32:13.0000] <GPHemsley>
element width trumps NBSP, right?

[19:32:25.0000] <GPHemsley>
explicit element width, that is

[19:49:15.0000] <zewt>
there's nothing special about nbsp in html, right? just a character that looks like a space but isn't a word break

[19:49:49.0000] <zewt>
(html has enough weirdness that I wouldn't be surprised if there was some random exception, but, well, hoping not and all that)

[20:06:00.0000] <zewt>
waiting for onload/onerror for an arbitrary image sure is a brittle pain without img.complete

[21:08:33.0000] <Hixie>
zewt: i think you're right, but check css and zcorpan's quirks spec

[22:36:51.0000] <MikeSmith>
when was AddSearchProvider added?

[22:36:55.0000] <MikeSmith>
does anybody implement it?

[22:37:14.0000] <MikeSmith>
oh

[22:37:17.0000] <Hixie>
pretty sure that's an ancient IE thing

[22:39:36.0000] <MikeSmith>
yeah

[22:51:15.0000] <gavin>
Firefox implements it

[22:52:04.0000] <gavin>
didn't seem that ancient to me but I guess we landed that in 2006 :/

[22:52:08.0000] <gavin>
(bug 337780)

[23:03:49.0000] <smaug____>
looks like a Google thing ;)

[23:24:58.0000] <MikeSmith>
I asked because html5test dude includes in his tests

[23:25:01.0000] <MikeSmith>
god knows why

[23:31:33.0000] <zcorpan>
sigh

[00:15:41.0000] <MikeSmith>
friends, I'm looking for a rough estimate of how much the performance of JS engines has improved over the last 4 years

[00:16:27.0000] <MikeSmith>
would it be accurate to say that current JS engines are on the order of 50 times faster than they were 4 years ago?

[00:17:23.0000] <paul_irish>
MikeSmith: i got data for you

[00:17:30.0000] <MikeSmith>
ok cool

[00:17:36.0000] <MikeSmith>
gimme data

[00:17:51.0000] <MikeSmith>
Feed me, Mandrake

[00:21:40.0000] <paul_irish>
MikeSmith: well. here is sunspider ie6-ie10 https://github.com/h5bp/lazyweb-requests/issues/11#issuecomment-2642244

[00:22:33.0000] <MikeSmith>
oool

[00:22:34.0000] <MikeSmith>
thanks

[00:22:37.0000] <paul_irish>
and here is dromaeo ie8 - http://paulirish.com/i/d914c0.png

[00:22:45.0000] <paul_irish>
ie8 through june 2012

[00:24:42.0000] <paul_irish>
MikeSmith: so.. based on the dromaeo, we're about 10x over 4 years ago

[00:24:57.0000] <MikeSmith>
oh

[00:25:06.0000] <paul_irish>
but its mostly a DOM speed test.

[00:25:06.0000] <MikeSmith>
ah yeah

[00:25:30.0000] <paul_irish>
if octane ran on ie8 it'd more illuminating, i bet

[00:28:07.0000] <MikeSmith>
I wonder if there are some other ways to give some quantitative info about the JS performance improvements, other than just benchmark data

[00:34:29.0000] <jgraham>
MikeSmith: Like what? At the point where you start getting quantative information from a specific application, it more or less *is* a benchmark, by definition

[00:34:38.0000] <MikeSmith>
yeah

[00:35:09.0000] <MikeSmith>
trying to figure out how to explain in to a reporter

[00:35:36.0000] <jgraham>
I mean a more relevant/understandable metric might be "these applications run fine on modern JS engines but are unusably slow on older browsers on the same hardware"

[00:37:20.0000] <MikeSmith>
yeah true

[00:40:20.0000] <jgraham>
Hixie: So, did you put your unload + document.open tests anywhere?

[00:49:28.0000] <MikeSmith>
I find the best way to respond to reporters is to mostly not pay attention to the actual questions they're asking me but instead regardless of the question just steer it around so I  keep repeating what I want them to put into the article

[00:50:09.0000] <jgraham>
/me adds "politician" to MikeSmith's career options

[00:50:13.0000] <odinho>
lol

[00:52:01.0000] <MikeSmith>
well, reporters are tricky dogs

[00:52:09.0000] <MikeSmith>
so you have to respond in kind

[00:52:36.0000] <MikeSmith>
they ask questions in this form like, "Would it be fair to say that...?"

[00:53:19.0000] <Ms2ger>
MikeSmith, thanks for the component :)

[00:53:28.0000] <MikeSmith>
np

[00:54:16.0000] <MikeSmith>
when they ask those questions, and if you say, "I dunno, I guess so, maybe", then they ends up writing that you believe that, in a way that makes it sound like you were the one who suggested it

[00:55:23.0000] <MikeSmith>
or after you tell them something, they say, "OK, understood, so from that would it be fair to say that you believe [some gross mischaracterization of what you just told them]."

[00:56:46.0000] <MikeSmith>
they basically have already written the article in their heads and they want to mis-ascribe the opinions to you

[00:57:17.0000] <MikeSmith>
anyway

[00:57:39.0000] <jgraham>
MikeSmith: So it would be fair to say that you think that all journalists should be sentenced to death?

[00:58:06.0000] <Ms2ger>
Looks like jgraham missed out on a career in journalism

[00:59:03.0000] <MikeSmith>
jgraham: :-)

[01:00:35.0000] <odinho>
Hmmmm. Robert Berjon made manifests for stuff in webapps, but he names it manifest.txt not MANIFEST as we've used before.  http://dvcs.w3.org/hg/webapps/rev/47eb68524cc5

[01:02:07.0000] <jgraham>
What's the point of those manifests?

[01:02:12.0000] <Ms2ger>
Oh, those are the useless CSSWG manifests

[01:02:22.0000] <jgraham>
They list which files are tests, which is fair enough]

[01:02:43.0000] <jgraham>
But they also give the test title? But no information about what part of the spec it is testing?

[01:03:21.0000] <odinho>
Seems a bit weird, I've used Ms2ger's version, where the normal version is just to list the names of the tests.

[01:07:24.0000] <smaug____>
Ms2ger: what is happening with parsing and serialization?

[01:07:37.0000] <smaug____>
you're writing a whatwg spec and MS writing w3 spec?

[01:07:51.0000] <Ms2ger>
Apparently so

[01:08:00.0000] <smaug____>
fun :/

[01:08:11.0000] <smaug____>
how did that happen

[01:15:58.0000] <Ms2ger>
HTMLWG

[01:16:16.0000] <Ms2ger>
And people who have to much time on their hands and nothing useful to do

[01:16:21.0000] <Ms2ger>
*too much

[01:17:25.0000] <smaug____>
Ms2ger: whaat? HTML Wg caused that?

[01:17:32.0000] <Ms2ger>
Yeah

[01:18:03.0000] <smaug____>
More reasons to not care about HTML Wg

[01:19:08.0000] <Ms2ger>
/me didn't need more reasons :)

[02:15:02.0000] <Martin_L>
Hi. I get mixed signals whether width/height-attributes on the img-tag are deprecated or not in html5. What is the case here, in´s in, it´s out or circumstatial?

[02:17:39.0000] <Martin_L>
F.e. Eric Meyer´s debug stylesheet, and some other sources says it´s out. Many other tuts and discussions says they are still kickin

[02:18:13.0000] <tomasf>
I don't see why they would be deprecated. they serve a valid purpose, don't they?

[02:18:17.0000] <tomasf>
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#dimension-attributes

[02:18:35.0000] <tomasf>
wait, oh

[02:18:56.0000] <jgraham>
Martin_L: In the spirit of "teach a man to fish" - http://www.whatwg.org/specs/web-apps/current-work/#the-img-element

[02:20:19.0000] <Martin_L>
jgraham: I agree, they serve a valid purpose, yes.

[02:20:47.0000] <jgraham>
Martin_L: (I didn't say that; tomasf did)

[02:21:33.0000] <Martin_L>
jgraham: tomasf: Oh crap, of cause. Sorry about that.

[02:23:25.0000] <zcorpan>
MikeSmith: reminder

[02:25:08.0000] <Martin_L>
tomasf: So I guess they are in then. Makes good sense. Thanks!

[02:25:40.0000] <tomasf>
np

[02:26:05.0000] <odinho>
zcorpan: Ms2ger got it already.

[02:26:15.0000] <Martin_L>
jgraham: And thank you too of cause

[02:26:47.0000] <odinho>
Martin_L: Never be afraid of reading the spec ;-)

[02:27:09.0000] <Martin_L>
odinho: Thats true :)

[02:49:44.0000] <odinho>
Is it really intended that we can't use variables in a sensible way any more? I mean I like [TreatUndefinedAs=Missing], why is it so discouraged to use?

[02:50:04.0000] <odinho>
I have to write totally stupid js code all the time to work around that.

[02:50:25.0000] <Ms2ger>
If you pass a variable, you pass it, no? :)

[02:50:52.0000] <odinho>
like openCursor(key, direction);   if direction is undefined, I have to set it to "next" manually. I don't see why it can't just fall back to its own default there.

[02:51:03.0000] <odinho>
I mean it stringifies  undefined  to "undefined" and throws.

[02:51:14.0000] <odinho>
That's rather unhelpful imho.

[02:51:31.0000] <jgraham>
odinho: That's how JS works

[02:51:46.0000] <odinho>
So I have to do something like   dir ? : dir = "next";  all over the place

[02:52:45.0000] <odinho>
And even for something like IndexedDB open, it's impossible to get the same behaviour with open('name', <second arg>) that you can get with open('name')

[02:53:23.0000] <odinho>
It's two different code paths. Not really that different, but you'll have to do    if (version) open(name, version) else open(name)

[02:53:58.0000] <odinho>
*supershrug*

[02:54:41.0000] <odinho>
Have to litter my code with stupid do-no-good tests. Grr. OK, rant over.

[03:11:01.0000] <jgraham>
Hmm, so if I window.open a window and then window.open a new document into the same window (by naming it the same), can I get the load event on the second document?

[03:11:14.0000] <jgraham>
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1730 doesn't work

[03:14:14.0000] <jgraham>
(in Opera it doesn't seem to be possible to get the load event at all)

[03:44:12.0000] <smaug____>
jgraham: shouldn't you use window.open

[03:44:16.0000] <smaug____>
not document.open

[03:45:06.0000] <smaug____>
or maybe it doesn't matter

[03:45:32.0000] <smaug____>
/me didn't remember this: // When called with 3 or more arguments, document.open() calls window.open().

[03:58:58.0000] <jgraham>
smaug____: That's exactly what I was testing

[04:00:11.0000] <jgraham>
But I can't really work out how to write a test that shows that the name argument is obeyed if I can't work out when the second document is loaded

[04:00:30.0000] <jgraham>
Also, I can't really work out why there is no event, so that is something that ought to be tested on its own

[04:10:18.0000] <jgraham>
(well of course I can write a test, just make the pass condition happen in a timeout. But that is ofc evil)

[04:12:39.0000] <zcorpan>
jgraham: does it help if you use an iframe with name=x and 'x' in open()?

[04:15:40.0000] <jgraham>
zcorpan: Not obviously

[04:16:18.0000] <zcorpan>
i thought you could use onload on the iframe

[04:16:44.0000] <zcorpan>
but it's a different case from opening a window, so maybe both should be tested anyway

[04:17:04.0000] <zcorpan>
sorry if i just gave you more work :-P

[04:19:13.0000] <Ms2ger>
TabAtkins, rearranged a bit

[04:24:59.0000] <jgraham>
zcorpan: No problem :) I already suffer from something like analysis paralysis writing tests here because there is so much to test, but working out the interesting cases is hard (it's all "what if I do X and then in the middle do something surprising"), then trying to write a test with a machine checkable pass condition turns out to be hard, or the test turns out to fail in some browsers for unrelated reasons, and then finally I find that the spec d

[04:25:58.0000] <zcorpan>
that the spec do...?

[04:26:38.0000] <jgraham>
Oh man, did I not /load splitlong.pl

[04:26:50.0000] <jgraham>
zcorpan: No problem :) I already suffer from something like analysis paralysis writing tests here because there is so much to test, but working out the interesting cases is hard (it's all "what if I do X and then in the middle do something surprising"), then trying to write a test with a machine checkable pass condition turns out to be hard, or the test turns out to fail in some browsers for unrelated reasons, and then finally I find that the spec d

[04:26:56.0000] <jgraham>
... implementation and don't know what to conclude (the spec is wrong, the implementations are wrong, life would be better sipping cocktails on a beach, etc.)

[04:27:57.0000] <zcorpan>
yeah

[04:28:14.0000] <jgraham>
So, using the load event on the iframe I can write the test I originally wanted to write, which is nice

[04:28:26.0000] <jgraham>
(albeit for iframes rather than windows)

[05:02:46.0000] <smaug____>
jgraham: so, IIRC, in Gecko script can get the load event if the inner window is reused when loading a document to just-opened window

[05:03:17.0000] <smaug____>
/me wonder what is the name for inner window in the spec... I guess it is Window

[05:10:27.0000] <jgraham>
smaug____: I am not sure I understand how that is different from what I tried

[05:17:55.0000] <smaug____>
jgraham: oh, I wasn't trying say it is different

[05:18:03.0000] <smaug____>
just explaining what happens in Gecko

[05:18:51.0000] <smaug____>
event listeners are added to the inner window, and if it changes while new document is loaded, then you ofc won't get events

[05:21:03.0000] <jgraham>
smaug____: But when I do win1 = window.open(/*stuff*/) and then attach a handler to win1.onload, I don't get a load event which only makes sense if the inner window changes after the event handler is attached, or the load event is sync

[05:22:52.0000] <smaug____>
inner window changes after that, I think

[05:23:02.0000] <smaug____>
but before the load event fires

[05:23:15.0000] <jgraham>
So chagning the inner window is async?

[05:23:48.0000] <jgraham>
/me notes that per spec this should just be a normal navigation

[05:25:51.0000] <smaug____>
jgraham: it is just a normal navigation

[08:42:24.0000] <dglazkov>
good morning, Whatwg!

[09:37:22.0000] <tantek>
dglazkov do you have a good morning script? ;)

[09:44:08.0000] <dglazkov>
tantek: nope. Only the desire for world peace through cheerfulness :)

[09:44:25.0000] <tantek>
:)

[09:44:51.0000] <tantek>
are you going to TPAC this year?

[09:45:38.0000] <tantek>
There's the start of a page about it on the W3C wiki: http://www.w3.org/wiki/TPAC2012

[09:45:58.0000] <tantek>
/me is on the program committee for the plenary day: http://www.w3.org/wiki/TPAC2012-Committee

[09:46:35.0000] <tantek>
and we're doing our planning for it out in the open in case you're curious, want to lurk, have comments: http://www.w3.org/wiki/TPAC2012-Planning

[09:54:16.0000] <Hixie>
jgraham: they're on hixie.ch/tests/adhoc/dom/level0/document/open/unload iirc

[09:54:21.0000] <Hixie>
jgraham: but they're not real tests yet

[09:55:08.0000] <Hixie>
1. make the spec not fire unload events at documents that are currently executing document.open()

[09:55:23.0000] <Hixie>
2. taking out the onbeforeunload for document.open()

[09:56:26.0000] <Hixie>
does that leave some sequence of events via nested iframes where you can get a loop...

[09:57:18.0000] <Hixie>
i guess not, since events only ever go down the tree, and each node can only get events so long as it's not doing d.o()

[09:57:25.0000] <Hixie>
/me tries to update his tests

[10:19:52.0000] <Ms2ger>
Yay, ap is quoting DOM 2 Events

[10:20:13.0000] <ap>
Ms2ger: care to quote any spec at all?

[10:20:49.0000] <Ms2ger>
Sure

[10:20:50.0000] <ap>
Ms2ger: and if that spec disagrees with previous spec, be sure to explain in detail why that was OK

[10:21:12.0000] <Ms2ger>
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#eventhandler

[10:21:28.0000] <Ms2ger>
And http://dev.w3.org/2006/webapi/WebIDL/#TreatNonCallableAsNull

[10:21:50.0000] <Ms2ger>
The spec disagrees with the previous spec because the previous spec wasn't implemented

[10:22:02.0000] <Ms2ger>
Except by webkit, apparently

[10:23:44.0000] <ap>
Ms2ger: it would be more effective to post that in the bug

[10:47:25.0000] <Hixie>
Ms2ger: yt?

[10:47:42.0000] <Ms2ger>
Yeah

[10:47:51.0000] <Hixie>
Ms2ger: MikeSmith asked us to let you know that he created the component for you so you can move the bugs over now

[10:48:06.0000] <Ms2ger>
Thanks, I already did :)

[10:48:59.0000] <Hixie>
cool

[10:50:21.0000] <Hixie>
ok i have a test which opera fails in one way, mozilla fails in a second, and webkit fails in a third

[10:50:28.0000] <Hixie>
and now IE for tie breaker!

[10:50:42.0000] <Hixie>
crap. IE fails it in a fourth way.

[10:52:34.0000] <Hixie>
browsers suck.

[10:53:09.0000] <Hixie>
IE appears to just end the script at document.open() during unload

[10:53:17.0000] <Hixie>
and opera ends the navigation

[10:53:55.0000] <Hixie>
both of those are too far from interop to be helpful

[10:54:13.0000] <Hixie>
gecko just ignores the document.write() calls

[10:54:28.0000] <Hixie>
that seems bad too

[10:54:32.0000] <Hixie>
that leaves webkit

[10:55:15.0000] <Hixie>
which seems to run the unloads for subframes only once... in response to the document.open(), though, not the original nav, and then it doesn't run it again for the original nav

[11:00:11.0000] <Hixie>
woah, document.open() in IE causes beforeunload to fire again

[11:00:24.0000] <Hixie>
also IE doesn't seem to fire pagehide at all

[11:01:15.0000] <Hixie>
i'm thinking a mixture of webkit and firefox behaviours is the way to go here

[11:01:44.0000] <Hixie>
have document.open/write work during unload, but make it so that the nested open() doesn't fire pagehide/unload events

[11:01:52.0000] <Hixie>
i wonder what happens when there's no navigation ongoing

[11:09:21.0000] <Hixie>
ok now looking at 003, which tests what events fire with a naked document.open()

[11:09:38.0000] <Hixie>
opera doesn't fire any (and is a pain about it cos it nukes timeouts extra hard somehow)

[11:10:15.0000] <Hixie>
firefox fires beforeunload on the doc being opened, then beforeunload, pagehide, and unload on subframes

[11:10:28.0000] <Hixie>
but it screws up the beforeunload handling, we learnt that yesterday

[11:11:33.0000] <Hixie>
webkit does the same as firefox except with no beforeunloads, which makes slightly more sense i think

[11:12:25.0000] <Hixie>
IE seems to kill the timeouts as aggressively as opera (weird)

[11:12:52.0000] <Hixie>
but it fires beforeunload for the top-level then the iframe, then unload for the top-level then the iframe

[11:13:07.0000] <Hixie>
so i guess that's what i was testing when i specced the spec

[11:15:58.0000] <Hixie>
and if you d.w() during the unload, IE jumps straight to the unloads, and then gives up on the original sequence of unloads...

[11:16:10.0000] <Hixie>
so you never get the inner frame's beforeunload

[11:16:11.0000] <Hixie>
interesting

[11:18:02.0000] <Hixie>
i don't understand what firefox does in this situation

[11:18:09.0000] <Hixie>
but not firing beforeunload seems reasonable

[11:18:25.0000] <Hixie>
so let's ignore beforeunload in this and try pagehide instead

[11:19:47.0000] <Hixie>
not firing the top level unload and pagehide makes sense too

[11:22:33.0000] <Hixie>
ok so if you have a subframe which, in its pagehide caused by the parent document.open()ing itself, tries to document.open() its parent, in firefox, you get two nested beforeunloads, but the second one doesn't see a pagehide

[11:24:13.0000] <Hixie>
o_O

[11:24:21.0000] <Hixie>
i got "parent is null" in one of these events (in an iframe)

[11:27:02.0000] <Hixie>
my head hurts

[11:28:40.0000] <Hixie>
that can't be right

[11:28:45.0000] <Hixie>
parent is null in unload in firefox?

[11:29:07.0000] <Hixie>
after you've done parent.document.write()?

[11:29:13.0000] <Hixie>
oh no

[11:29:26.0000] <Hixie>
nevermind

[11:30:30.0000] <Hixie>
IE seems to just have lots of checks that you're involved in a loop, which just bail out of the loop as soon as they detect one

[11:31:16.0000] <Hixie>
i don't understand what firefox is doing

[11:31:59.0000] <Hixie>
or webkit for that matter

[11:46:36.0000] <Hixie>
ok let's see... if we just make the unload algorithm bail on nested unloads, that's pretty close to what browsers do...

[11:51:12.0000] <Ms2ger>
Hixie, I guess it's Anne's fault that http://dom.spec.whatwg.org/ doesn't update? :)

[11:51:33.0000] <Hixie>
yes

[11:51:37.0000] <Hixie>
i hope :-)

[11:53:07.0000] <Hixie>
...damnit, that breaks the regular nav case.

[11:53:07.0000] <Hixie>
hmm

[12:11:58.0000] <Hixie>
wtf is webkit doing

[12:13:22.0000] <Hixie>
maybe it does everything up to the document.open(), but then runs the unload again, skipping any events that were sent the first time?

[12:13:25.0000] <Hixie>
hmm

[12:15:15.0000] <Hixie>
oooh, interesting

[12:15:39.0000] <Hixie>
it _does_ ignore parent.document.open() from a child unload....

[12:15:51.0000] <Hixie>
well not so much ignore as abort...

[12:18:19.0000] <Hixie>
i'm rapidly starting to see the aesthetic beauty of firefox's hardline "no document.open() during unloads" approach

[12:42:27.0000] <Hixie>
IE's behaviour here really makes no sense

[12:42:36.0000] <Hixie>
why would you call beforeunload again before aborting

[12:44:00.0000] <Hixie>
none of these browsers make any sense

[12:45:06.0000] <Ms2ger>
/me points at the topic

[12:46:02.0000] <Hixie>
ok this is absurd

[12:46:21.0000] <Hixie>
IE behaves differently if i follow a link than if i reload than if i select the url in the address bar and hit enter

[12:47:10.0000] <Hixie>
it varies between opera's behaviour if i reload, doing nothing at all if i hit enter, and some wacky behaviour if i follow a link

[14:11:06.0000] <dsheets>
"Please leave your sense of logic at the door, thanks!" does not bode well.

[14:18:24.0000] <Hixie>
dsheets: welcome to the web :-(

[14:18:57.0000] <Hixie>
/me is living that catchphrase right now trying to work out how document.open() should work when called from the unload handled of an iframe that is being unloaded because a parent frame's document.open() was called

[14:28:06.0000] <dsheets>
Hixie: http://en.wikipedia.org/wiki/Principle_of_explosion

[14:33:13.0000] <Hixie>
quite

[15:01:53.0000] <Hixie>
w

[15:01:53.0000] <Hixie>
t

[15:01:54.0000] <Hixie>
f

[15:02:22.0000] <Hixie>
having established that NONE of the browsers behave even REMOTELY interoperably, i make some compromises and write a test that assumes them

[15:02:29.0000] <Hixie>
all the browsers fail, IN THE EXACT SAME WAY

[15:03:16.0000] <Hixie>
well, except IE

[15:03:24.0000] <Hixie>
no idea what IE is doing

[15:04:52.0000] <deane>
Hang in there, Hixie,

[15:09:00.0000] <Hixie>
oh i know what's wrong

[15:21:42.0000] <Hixie>
ok with http://www.hixie.ch/tests/adhoc/dom/level0/document/open/unload/001.html firefox is close to passing what the spec says now

[15:22:06.0000] <Hixie>
IE is miles off. Opera has some more fundamental bugs with unload and d.o() so it's not in the running.

[15:22:30.0000] <Hixie>
webkit doesn't block off d.o() so it gets it wrong but that seems like something that shouldn't be too hard to fix

[15:23:32.0000] <GPHemsley>
/me finds it interesting that no one ever seems to read the RFC 2119 errata.

[15:23:33.0000] <Hixie>
http://www.hixie.ch/tests/adhoc/dom/level0/document/open/unload/002.html in webkit almost passes, it just forgets to fire beforeunload events and load/pagehide events in the current frame

[15:23:59.0000] <GPHemsley>
/me wonders if that makes it worth replacing RFC 2119 with a new RFC that has the errata fixed.

[15:24:00.0000] <Hixie>
GPHemsley: no-one reads any rfc's errata (or w3c tr/ page rec errata)

[15:24:09.0000] <GPHemsley>
:)

[15:24:16.0000] <Hixie>
that's one of the many reasons snapshot spec dev is bogus :-)

[15:24:28.0000] <GPHemsley>
Ah! Good argument!

[15:24:50.0000] <GPHemsley>
But nevertheless, the RFC 2119 errata actually change the requirement for what an RFC 2119-compliant document must say.

[15:25:01.0000] <GPHemsley>
(due to an accidental omission)

[15:25:35.0000] <GPHemsley>
as a result, few people use the errata-corrected statement in their specs—living or otherwise

[15:27:24.0000] <Hixie>
does HTML get it right?

[15:27:37.0000] <Hixie>
(whatwg.org/html)

[15:28:29.0000] <Hixie>
gecko gets http://www.hixie.ch/tests/adhoc/dom/level0/document/open/unload/002.html almost right, it just doesn't fire unload and pagehide in the current doc for some reason

[15:28:47.0000] <Hixie>
(though it does fire beforeunload)

[15:28:58.0000] <Hixie>
opera is again off in the weeds

[15:29:09.0000] <zewt>
but you can't change the text of a spec once it's etched in concrete! because... because...

[15:29:33.0000] <zewt>
nothing is quite as painful as reading spec-diffs

[15:29:34.0000] <Hixie>
IE gets it right except for pagehide not firing because

[15:29:52.0000] <Hixie>
zewt: how about implementing a diff spec?

[15:29:59.0000] <Hixie>
zewt: (as wf2 was)

[15:30:26.0000] <zewt>
every opengl extension is like that

[15:30:32.0000] <zewt>
big lists of "add this text to this section"

[15:30:57.0000] <Hixie>
(i wonder why the people who are all up in arms against living standards aren't up in arms against errata)

[15:31:49.0000] <zewt>
possibly because many of those people have "because we've always done it this way" mindsets

[15:32:13.0000] <Hixie>
ah, conservatism

[15:33:28.0000] <zewt>
conservatism itself isn't necessarily bad; changing how major things are done should be done with care--some people just go well beyond that

[15:33:45.0000] <zewt>
(as i'm sure you know :)

[15:34:05.0000] <Hixie>
nah, clearly we should just continually change things!!! :-)

[15:34:09.0000] <Hixie>
for the sake of it

[15:34:13.0000] <zewt>
it's fun!

[15:34:19.0000] <Hixie>
keeps people on their toes

[15:34:28.0000] <zewt>
so do tacks

[15:34:31.0000] <GPHemsley>
:)

[15:34:42.0000] <Hixie>
i'd think tacks keeps people in their shoes

[15:34:55.0000] <zewt>
also the "we learned this thing through experience 15 years ago, and therefore it applies for all time"

[15:35:24.0000] <Hixie>
yeah well as i'm learning first hand today, things that we learnt through experience years ago can be wrong just because we didn't do a good job learning

[15:35:47.0000] <Hixie>
e.g. clearly my testing for document.open() and unload was inadequate back whenever i wrote this prose

[15:35:50.0000] <zewt>
such as new software still pretending that arbitrary encoding support is important--after all, we learned at great pain that it was important years ago, and hey, we might want to change away from utf-8 soon!

[15:36:09.0000] <Hixie>
yeah, also, it's not like the Web has come up since the IETF was started

[15:36:15.0000] <Hixie>
so nothing has changed there

[15:36:33.0000] <GPHemsley>
Hixie: The erratum is the exclusion of the phrase "NOT RECOMMENDED" in the list of RFC 2119 expressions. So no, HTML doesn't get it right. And neither does DOM4.

[15:36:40.0000] <zewt>
of course, you and I differ on some points I'd place in this category, such as sites requiring javascript :)

[15:37:17.0000] <zewt>
(but life would be boring if everyone agreed on everything, wouldn't it)

[15:37:18.0000] <Hixie>
GPHemsley: actually HTML does get _that_ right, it doesn't use the terms RECOMMENDED per RFC2119

[15:37:37.0000] <GPHemsley>
"The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119."

[15:37:46.0000] <GPHemsley>
section 2.2

[15:38:26.0000] <zewt>
what the heck

[15:38:35.0000] <zewt>
http://www.rfc-editor.org/errata_search.php?rfc=2119 is this really the official place to get rfc errata

[15:38:55.0000] <zewt>
i searched for "rfc2119 errata", this was the top link, and i closed it because it looked like some cheesy third-party site in order to find the real one

[15:39:00.0000] <Hixie>
GPHemsley: huh

[15:39:00.0000] <zewt>
... but then the rfc itself linked me here

[15:39:24.0000] <Hixie>
GPHemsley: thanks for finding that

[15:39:31.0000] <Hixie>
GPHemsley: i need to make sure the spec is fixed there

[15:39:47.0000] <zewt>
i can see why nobody reads errata; i have to wade through needless typo fixes in order to find anything meaningful

[15:40:17.0000] <zewt>
can't just filter it; it has typo/grammar fixes marked "technical"

[15:40:24.0000] <Hixie>
GPHemsley: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=18761

[15:40:25.0000] <GPHemsley>
zewt: And then there's the fact that the BCP pages don't link to the errata pages of the RFCs that make them up

[15:41:03.0000] <GPHemsley>
Hixie: K. What should I do about DOM4?

[15:41:56.0000] <zewt>
(2012 and reading RFC2119 is still formatted for an 80x60 fixed-width printer)

[15:42:08.0000] <Hixie>
GPHemsley: file a bug on it i guess :-)

[15:42:28.0000] <Hixie>
GPHemsley: it should say how to do that somewhere in the spec at the top

[15:42:32.0000] <GPHemsley>
ah

[15:42:33.0000] <GPHemsley>
ok

[15:42:55.0000] <GPHemsley>
Ah, not part of the WHATWG component

[15:43:32.0000] <Hixie>
well that sucks

[15:43:48.0000] <Hixie>
once again there is interop on a test i wrote, where the interop is all not matching the spec

[15:44:01.0000] <zewt>
GPHemsley: bugzilla's component system is pretty nightmarish, heh

[15:44:04.0000] <Hixie>
but this is after i carefully aligned the spec to match the compromise of everything the browsers did on other tests

[15:45:30.0000] <Hixie>
wtf

[15:45:39.0000] <Hixie>
why are they all obeying document.open() in beforeunload!

[15:45:43.0000] <Hixie>
that is THE MAKING OF NO SENSE

[15:46:37.0000] <Hixie>
you can't allow document.open() in beforeunload AND fire beforeunload on document.open()!

[15:47:00.0000] <zewt>
oh? watch us!

[15:48:19.0000] <GPHemsley>
Hixie: Welcome to the Hotel California. :)

[15:49:06.0000] <Hixie>
i like how the browsers conveniently don't refire beforeunload in this one case

[15:49:22.0000] <Hixie>
because, you know, WHY BOTHER BEING CONSISTENT

[15:50:04.0000] <GPHemsley>
DOM4 bug is here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18763

[15:50:31.0000] <GPHemsley>
Hixie: I'm sure they've all thought about this as much as you had right before you started thinking about it. ;)

[15:50:45.0000] <Hixie>
possible

[15:51:28.0000] <zewt>
bleh, Object.freeze seems more confusing than useful without strict mode to make sure it causes exceptions to be thrown, and strict mode sounds more dangerous than not with all the "awooga awooga: this causes varying behaviors" warnings around it

[15:51:49.0000] <Hixie>
c.f. modes considered harmful

[15:52:00.0000] <zewt>
and i guess ie9 doesn't support it

[15:52:07.0000] <zewt>
so many years until it's viable

[15:52:53.0000] <Hixie>
ok i guess we can have one counter for onunload and one for onbeforeunload

[15:53:07.0000] <Hixie>
the onunload one would prevent d.o() from being called from unload

[15:53:19.0000] <Hixie>
the onbeforeunload would prevent d.o() from calling beforeunload

[15:53:33.0000] <Hixie>
because WHY NOT

[15:53:35.0000] <zewt>
i'll take the possibility of having a less-stupid-javascript mode down the road, but until it's universally supported (eg. until it's not *actually* a varying mode that I have to test both sides of), no thanks

[15:54:03.0000] <Hixie>
the other possibility is that i just say all the browsers are wildly wrong on this one test case and hope the implementors agree

[15:54:32.0000] <Hixie>
any implementors around want to try to convince me one way or the other?

[15:54:43.0000] <Hixie>
more complexity but closer to current browsers; or further from current browsers but simpler?

[15:54:55.0000] <Hixie>
(there's no serious interop here)

[15:56:58.0000] <GPHemsley>
I think if the browser implementations vary wildly, it's probably the prime opportunity to bring logic *back* into the conversation

[15:57:06.0000] <GPHemsley>
just do whatever seems most logical

[15:58:14.0000] <GPHemsley>
(or does that not make it easier?)

[16:00:23.0000] <GPHemsley>
since they all do wildly different things, it seems OK to penalize them all for lack of logic and/or interoperability

[16:22:05.0000] <Hixie>
GPHemsley: well, in theory i agree, but if that implies a greater delta from existing implementations, it's possible they'll prefer to remain where they are than risk change

[16:22:41.0000] <GPHemsley>
I'd be surprised if that were the case... but at least plan B isn't terrible :)

[16:23:28.0000] <Hixie>
i wouldn't at all be surprised one way or the other :-)

[16:24:52.0000] <GPHemsley>
/me shrugs

[16:32:21.0000] <GPHemsley>
Hixie: I thought vendor prefixes were Bad™?

[16:32:44.0000] <Hixie>
reality is more subtle; what's the specific case we're talking about?

[16:33:05.0000] <zewt>
"Considered Harmful" Considered Harmful

[16:33:08.0000] <GPHemsley>
just reading Section 2.2.3

[16:33:27.0000] <Hixie>
GPHemsley: that's abotu proprietary extensions, no?

[16:33:44.0000] <GPHemsley>
oh, yeah, maybe

[16:33:46.0000] <Hixie>
GPHemsley: the "vendor prefixes are bad" thing is usually regarding experiments driven from specs with active editors

[16:33:59.0000] <Hixie>
the key is just what'll get interop faster, basically

[16:34:05.0000] <GPHemsley>
I see

[16:34:22.0000] <GPHemsley>
so if it's already specced, they're bad

[16:34:28.0000] <GPHemsley>
but if it's not, then s'ok

[16:34:34.0000] <GPHemsley>
?

[16:34:44.0000] <zewt>
not inherently, but they can be used badly (eg. for too long, etc)

[16:35:20.0000] <Hixie>
man opera is so far away from the others on this document.open/unload thing that it's just kinda funny testing it

[16:35:34.0000] <Hixie>
GPHemsley: it's more subtle than that, but to a rough first approximation, ok

[16:36:21.0000] <zewt>
the prefixing concept is generally under reevaluation, and there isn't yet a consensus, so you'll get different answers depending on who you ask :)

[16:36:58.0000] <Hixie>
well that's true about 'most anything

[16:37:14.0000] <zewt>
well, more so than it was until relatively recently

[16:38:05.0000] <Hixie>
don't confuse silent disagreement or undiscovered disagreement for agreement

[16:38:14.0000] <Hixie>
any more than violent discussion should be confused for disagreement

[16:38:32.0000] <Hixie>
e.g. my position on prefixes hasn't changed in years

[16:38:38.0000] <zewt>
private disagreement is different than general community-wide reevaluation, though

[16:38:52.0000] <zewt>
call it disagreement with more momentum if you like :)

[16:38:54.0000] <Hixie>
communities don't reevaluate things

[16:38:56.0000] <Hixie>
people do :-)

[16:46:19.0000] <Hixie>
one and a half days' work resolved one bug.

[16:46:25.0000] <Hixie>
not gonna make my targets at THAT rate!

[16:46:51.0000] <zewt>
you could do what lots of projects do in my experience

[16:46:56.0000] <zewt>
periodically close all old bugs!

[16:47:17.0000] <Hixie>
my goal isn't to get to zero bugs

[16:47:23.0000] <Hixie>
my goal is to resolve all bugs

[16:47:30.0000] <Hixie>
:-P

[16:49:48.0000] <Hixie>
jgraham's idea of putting the bug numbers in the spec, or rather, his actually doing it, is simply genius