04:57
<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 :-/
08:29
<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.
08:32
<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)).
11:05
<jgraham>
MikeSmith: Any chance of getting the WebPerf testsuite mirrored on github?
11:05
<MikeSmith>
jgraham: sure I'll try to get it set up tomorrow
11:05
<jgraham>
MikeSmith: (eventually I plan to ask this for all web-relevant testsuites on dvcs.w3.org :)
11:05
<jgraham>
MikeSmith: Great, thanks
15:08
<TabAtkins>
Hixie: I'm glad I rank so highly in your mind that you confer all the good suggestions on me, though. ^_^
15:14
<Hixie>
TabAtkins: :-)
15:16
<Hixie>
MikeSmith: it was my understanding that under iana/w3c rules, you didn't have to send registrations to the iana?
15:16
<Hixie>
MikeSmith: at least, not until REC, or something?
15:16
<MikeSmith>
I was asked to send those.
15:16
<Hixie>
by whom?
15:16
<MikeSmith>
plh
15:16
<MikeSmith>
after he talked to IETFers last week I guess
15:17
<Hixie>
is the w3c/iana agreement no longer in force then?
15:17
<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.
15:17
<Hixie>
ah
15:17
<MikeSmith>
Hixie: not sure
15:18
<MikeSmith>
I just wanted to clear away an action item. If they don't act on it, I won't mind.
15:19
<Hixie>
oh i guess the process is actually when going to LC, so nevermind
15:20
<Hixie>
speaking of mime types, we really need to get on with the replacement for the iana registry
15:27
<zewt>
grr @ clientHeight/Width being 0 on elements with hidden parents
15:27
<zewt>
whoever decided on that must seriously hate other programmers
15:27
<TabAtkins>
You mean [hidden] parents, right?
15:28
<Ms2ger>
display:none parents
15:28
<TabAtkins>
Yeah.
15:28
<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.
15:28
<TabAtkins>
(And that would, indeed, seriously impact performance on many sites.)
15:29
<TabAtkins>
s/rendering and//
15:29
<zewt>
only if the attributes are examined
15:30
<zewt>
(and if you want to keep them from being accidentally hit, move it to a function)
15:31
<zewt>
i feel like a circus animal at times with the amount of hoop-jumping APIs make me do, heh
15:48
<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?
15:53
<Hixie>
that sounds unlikely, let me check
15:54
<Hixie>
do you have an example of what is missing?
15:54
<Hixie>
quick spot-check doesn't find me anything missing
15:57
<Ms2ger>
Hixie, if I have a cross-origin window that contains a frame with name foo, should I be able to access window.foo?
15:58
<Hixie>
beats me
15:58
<Hixie>
what does the spec say and what do UAs do?
15:59
<Ms2ger>
I was hoping to avoid the testing part :)
16:00
<Ms2ger>
The spec says no for window.foo, but yes for window[0], I think
16:01
<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
16:01
<Hixie>
not sure if it matches in the exact case you mention
16:01
<Hixie>
the thing that was brought up was about navigation, iframes, and window.name, iirc
16:01
<Ms2ger>
Ah, yes
16:01
<Ms2ger>
bz filed that, I think
16:02
<Ms2ger>
This code is horrible in Gecko ::
16:02
<Ms2ger>
:/
16:02
<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
16:03
<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
16:03
<Ms2ger>
That's assuming people who care about the W3C fork write tests :)
16:03
<Hixie>
i would imagine any microsoft-contributed tests will be written to that spec
16:04
<Hixie>
insofar as they are written to any spec, anyway
16:04
<Hixie>
anyway, if anyone has any suggestions, ideas, input, etc, on this front, let me know
16:05
<Hixie>
(i'm happy to let the issue lie until a fork affects the test suite)
16:05
<Ms2ger>
Hmm, MS submitted tests in April, that's more recent than I'd expected
16:06
<Hixie>
tobie: (ping, in case you missed that i replied earlier)
16:13
<tobie>
Hixie, I had, sorry. For example, can't find "candidate" in the spec.
16:16
<tobie>
Hixie: I might be incorrectly assuming all of the said changes are in the offline section only.
16:17
<Hixie>
tobie: oh, i didn't realise you meant specifically only the offline section. Yeah, the changes are all over.
16:18
<tobie>
Hixie: my bad.
16:18
<Hixie>
tobie: navigation algorithm, in particular, has some core stuff
16:19
<tobie>
yeah, makes sense now (and explains why it's hard to pull app cache out of the spec).
16:20
<tobie>
Hixie: the svn repo's private, right?
16:21
<Hixie>
svn.whatwg.org/web-apps
16:21
<Hixie>
public read
16:21
<Hixie>
yeah, pulling appcache out would be seriously painful
16:21
<Hixie>
it's deeply integrated with history and navigation
16:21
<Hixie>
it'd be like pulling out frames or something :-)
16:21
<Ms2ger>
We could pull out history and navigation as well ;)
16:22
<tobie>
Hixie: beautiful, thanks.
16:23
<Hixie>
tobie: if you want blame files, they take forever to generate, but i have a bunch of them cached
16:23
<Hixie>
tobie: so let me know if that's what you're looking for
16:26
<tobie>
Hixie: won't need them now, but good to know those exist.
16:27
<Hixie>
whenever you want them, let me know and i'll give you the urls
16:27
<Hixie>
(i add more to the list as i need them)
16:39
<tobie>
Hixie: if those are online, then sure, the urls would be helpful.
16:41
<jgraham>
Hixie: Yeah, I am quite bothered about the testing thing
16:41
<jgraham>
It seems like one of the few downsides of the split :(
16:43
<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
16:44
<Hixie>
jgraham: what's the current state of testing?
16:44
<tobie>
Hixie: Thanks
16:45
<jgraham>
Hixie: In what sense?
16:46
<jgraham>
There are some mercurial repos
16:46
<jgraham>
Various people have contributed tests including MS
16:46
<jgraham>
For HTML, the testing TF is chaired by Kris from MS
16:47
<jgraham>
Obviously the testsuites aren't great yet, but they're not trivial either
16:47
<Ms2ger>
Which means he mostly talks to himself for an hour on IRC every two weeks
16:47
<zewt>
jgraham: are there any requirements on test licensing to make sure the tests can be reused? (eg. by whatwg)
16:48
<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?
16:50
<jgraham>
Hixie: In theory that should work
16:50
<Hixie>
but in practice?
16:50
<jgraham>
Hixie: Dunno, I haven't tried :)
16:51
<Hixie>
ah, right
16:51
<jgraham>
Although our plan is to do something similar for hosting the tests inside Opera
16:51
<Hixie>
jgraham: anyone tried writing tests for the stuff we've fixed in whatwg but not htmlwg yet?
16:51
<jgraham>
Hixie: Not as far as I know
16:52
<jgraham>
There have been some small problems due to W3C specs being split and missing X-refs needed to make definitions clear
16:52
<Hixie>
is there a plan for testing features only specced on the whatwg side, like srcset=""?
16:52
<smaug____>
conf calls can be hard "...fell asleep while waiting for the call in front of my computer"
16:52
<Ms2ger>
Just check them in, and see if anybody whines? :)
16:53
<jgraham>
My plan would be to submit tests and see what happens
16:53
<Hixie>
well, yeah, that's kinda where i was heading with this
16:53
<jgraham>
Ms2ger: Exactly
16:53
<jgraham>
I kind of expect MS to object
16:53
<jgraham>
and no one else to care
16:53
<Hixie>
i'd be interested in seeing what would happen
16:54
<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
16:54
<Hixie>
er
16:54
<Hixie>
mispaste
16:54
<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?
16:54
<Hixie>
the first bullet has a link to all the changes since the htmlwg side froze
16:54
<Hixie>
and the list at the bottom has some features that are entirely missing on the htmlwg side
16:55
<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.
16:55
<Hixie>
e.g. if you need servers or whatnot.
16:56
<Ms2ger>
Dammit, you linked me to single-page :)
16:56
<Hixie>
i only use the single-page :-P
16:56
<Hixie>
multipage takes too long to load
16:56
<Hixie>
:-P
16:57
<Hixie>
(single-page just has to be loaded once and left loaded)
16:57
<Ms2ger>
The data element?
16:57
Ms2ger
never even heard of it
16:57
<Hixie>
what about it?
16:57
<Hixie>
oh
16:57
<Hixie>
replaced the old <time>
16:57
<Hixie>
(a new <time> was later introduced to complement <data>)
16:57
<Ms2ger>
Oh
16:59
<garciawebdev>
good morning
16:59
<garciawebdev>
can the Origin request header be changed?
16:59
<garciawebdev>
from JS?
16:59
<Hixie>
short answer, no
16:59
<zewt>
that would seem to defeat its purpose
16:59
<Hixie>
long answer, which header, exactly? (and then still, no)
17:00
<Hixie>
(what are you trying to do?)
17:01
<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)
17:01
<Hixie>
ah, yeah, that's pretty much exactly what we're trying to prevent :-)
17:01
<garciawebdev>
I see
17:01
<Hixie>
(so that a hostile site can't "do stuff" to your bank details, e.g.)
17:02
<Hixie>
if you don't have to do it from a web page, though, you can just write a script
17:02
<garciawebdev>
I see
17:02
<Hixie>
then the origin dosn't matter
17:02
<Hixie>
also, if you control the other site, you can have it implement CORS and side-step the issue
17:02
<garciawebdev>
yes, I think I'll end doing it on the server-side
17:02
<garciawebdev>
(no, I don't control the server side)
17:03
<garciawebdev>
it's something almost identical to Pinterest
17:03
<garciawebdev>
(yeah, don't ask why, "client demands")
17:04
<garciawebdev>
so you enter the URL and it looks for pinnable images
17:04
<garciawebdev>
for any site you enter
17:05
<garciawebdev>
so I don't control the URL entered by the user to enable CORS
17:05
<garciawebdev>
but will go with making a server side request
17:08
<garciawebdev>
thanks Hixie
17:10
<gsnedders>
garciawebdev: The other option would be making browser extension, and then syncing it up to server.
17:14
<garciawebdev>
gsnedders: how is that?
17:28
<zewt>
gsnedders: browser extensions are ... usually not really an option for public sites, heh
17:32
<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
17:32
<MikeSmith>
and also for the whole misguided text type vs application type artificial division
17:32
<Hixie>
depends what hte goal is
17:33
<MikeSmith>
well, we should just get rid of the application types completely, for starters
17:33
<Hixie>
if the goal is to replicate the iana registry, then it's probably pointless to bother, they already exist
17:33
<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
17:33
<MikeSmith>
yeah
17:33
<Hixie>
or maybe the goal should be to make MIME types irrelevant
17:33
<Hixie>
or... i dunno
17:33
<MikeSmith>
I don't want to re-do all that vnd.* madness
17:34
<Hixie>
certainly one could imagine making a simpler wiki-style registration mechanism first-come-first-served
17:34
<Hixie>
that doesn't require a Real Spec, just a brief description
17:34
<MikeSmith>
well, restricting it to mime types that are actually relevant to the Web would be a good start
17:34
<Hixie>
and that encourages text/* for text formats, e.g.
17:34
<MikeSmith>
yeah
17:34
<gsnedders>
zewt: No, but depends on what is wanted.
17:35
<Hixie>
anyway, i haven't looked into it, so i'm not really sure what the goal should be
17:35
<Hixie>
the current system is clearly broken, but maybe it's the least broken it could be
17:35
<Hixie>
and maybe it's far more broken than necessary
17:35
<Hixie>
i haven't investigated enough to say
17:37
<MikeSmith>
something that doesn't require dealing with IETF/IANA process would certainly be a plus
17:38
<MikeSmith>
coming to realize more and more that there's a cultural difference there which is very hard to bridge
17:39
<MikeSmith>
e.g., a standards culture that doesn't mandate test cases and implementation reports before a making something a standard
17:39
<MikeSmith>
or doesn't in fact even encourage it
17:39
<Ms2ger>
The W3C?
17:39
<Ms2ger>
Oh
17:41
<MikeSmith>
Ms2ger: you should be assigned to only deal with IETF work for 3 months
17:41
<Ms2ger>
Do you want me dead? ;)
17:41
<gsnedders>
Well, you are nobody. You are Ms2ger.
17:41
<MikeSmith>
have dudes carefully explaining to you why Unicode is bad idea
17:41
<MikeSmith>
where cranks are the norm
17:41
<Ms2ger>
I wonder if they would like pseudonymous people more than the W3C
17:42
<MikeSmith>
instead of "Leading the Web to its full potential", the motto is "Wingnuts fully welcome!"
17:45
<Ms2ger>
Maybe I should try that when the W3C kicks me out
17:46
<MikeSmith>
Ms2ger: there's the guy at IETF who pioneered standards pseudonimity, "m" somebody
17:46
<TabAtkins>
Yeah, after the "m" there were some other character, like "ger", and maybe a number.
17:47
<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
17:48
<Hixie>
i was honestly shocked when websockets when to ietf and i got to experience ietf first-hand
17:49
<Hixie>
i had no idea there could be a group worse than w3c in terms of things like bureaucracy, mis-prioritising, etc
17:49
<zewt>
the only IETF spec i've implemented myself was XMPP, and that made me never want to touch an ietf spec again
17:49
<MikeSmith>
but then they turn around and be the first ones to complain about Ms2ger. Because he's not part of their club
17:49
<zewt>
it basically seemed like a big maze of "shoulds" and "mays" and very little behavior that you could ever depend on
17:49
<Ms2ger>
Hixie, #firstworldproblems
17:50
<Ms2ger>
MikeSmith, oh? They complained?
17:50
<MikeSmith>
zewt: you will enjoy reading the OAuth 2.0 spec. Even the people who wrote it don't know what it says.
17:51
<Ms2ger>
The OAuth guy's blog post was interesting
17:51
<MikeSmith>
Ms2ger: yeah some people complained that since you don't have a Facebook account they can't trust you
17:51
<Ms2ger>
Heh
17:51
<Ms2ger>
I have two
17:51
<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. :-)
17:51
<Hixie>
MikeSmith: is THAT why they don't trust me? :-P
17:51
<zewt>
(also implemented the stringprep profile and some SASL bits, which were at little less "shouldy" but still painful)
17:51
<MikeSmith>
Hixie: heh
17:52
<Ms2ger>
A fun question for you all
17:52
<Ms2ger>
<iframe name=constructor></iframe>
17:52
<zewt>
MikeSmith: to state the obvious, I don't think I can trust anyone who bases trust on Facebook :)
17:52
<Ms2ger>
What is window.constructor?
17:52
<Hixie>
Ms2ger: the spec has an answer, dunno if it's the right one :-)
17:53
<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
17:54
<Hixie>
if it makes you feel better, it makes me feel outside too
17:54
<Hixie>
and i'm the editor...
17:54
<Ms2ger>
Making the editor feel outside appears to be standard practice at the IETF
17:55
<Hixie>
man, we're all quite grumpy today :-P
17:55
<MikeSmith>
Ms2ger: of course man
17:55
<TabAtkins>
If it makes you feel better, I'm quite cheeful.
17:56
<Ms2ger>
Because you only need to deal with the CSSWG?
17:56
<Ms2ger>
Wouldn't make me cheerful :)
17:56
<MikeSmith>
the reactionary hive mind is always what's more important
17:56
<MikeSmith>
TabAtkins: rename some more flexbox properties man
17:56
<TabAtkins>
MikeSmith: Nah, I'm past that. I'm going to rewrite gradient syntax instead.
17:57
<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 "
17:57
<MikeSmith>
poor @mat
17:57
<Hixie>
o_O
17:57
<Hixie>
yeah mike
17:57
<Hixie>
why aren't you compiling security guidelines
17:57
<Ms2ger>
Clearly the UN needs to take over the internet and require everyone to follow those guidelines
17:58
<MikeSmith>
I will stop everything I'm doing on get started right away on finding ways to save @mat from his own stupidity
17:58
<Hixie>
what did this @mat person do
17:58
<MikeSmith>
got hacked
17:58
<jgraham>
Actually we had some interesting internal feedback on CSP
17:59
<Hixie>
(the funniest part of that quote above btw is the implication that "webdev" read anything we write)
17:59
<MikeSmith>
jgraham: yeah? like what?
17:59
<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
17:59
<Ms2ger>
Oh, is that the guy with the Apple/Adobe accounts?
17:59
<MikeSmith>
Ms2ger: yeah
18:00
<MikeSmith>
jgraham: no surprise there I guess
18:00
<Hixie>
oh then that quote is even funnier since it wasn't a web vulnerability...
18:00
<zewt>
Hixie: hey, I do :)
18:00
<jgraham>
So the person trying it out basically gave up
18:00
<MikeSmith>
when browsers enable extensions mechanisms that allow extensions to do pretty much anything they want, well...
18:00
<MikeSmith>
it's the same with native mobile apps, really
18:00
<scott_gonzalez>
Hixie: Do you have an rough idea of when you might get around to discussing window.onerror() improvements?
18:01
<jgraham>
MikeSmith: Hard to have an extension mechanism that is both useful and doesn't allow you to add content to web pages
18:01
<MikeSmith>
scott_gonzalez: ?? what specifically? Are the current problems documented somewhere?
18:01
<zewt>
jgraham: well, "simple" javascript interface extensions can be extremely useful by themselves
18:01
<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
18:02
<zewt>
(that is, ones which expose interfaces and maybe fire events but don't touch the DOM directly)
18:02
<MikeSmith>
jgraham: yeah. Same with native apps. People install mobile apps with very little awareness or concern about what they might be doing.
18:03
<scott_gonzalez>
Hixie: I'm not an implementor, I'm a project lead for jQuery.
18:03
<MikeSmith>
Hixie: what's wrong with current window.onerror() ?
18:03
<scott_gonzalez>
MikeSmith: There's a few months old thread, let me find it.
18:03
<Hixie>
MikeSmith: people want a stack trace
18:03
<MikeSmith>
ah
18:03
<Hixie>
if it's the feedback i think it is
18:03
<MikeSmith>
yeah me too
18:03
<MikeSmith>
actually
18:03
<scott_gonzalez>
Hixie: Yes, that's correct.
18:03
<MikeSmith>
well, let's do that
18:04
<MikeSmith>
Hixie: make it happen
18:04
<Hixie>
it has some security implications (we'd have to hide frames from other origins)
18:04
<Ms2ger>
tc39 is speccing some sort of Error.stack, IIRC
18:04
<Hixie>
Ms2ger: there's not always an Error
18:04
<scott_gonzalez>
Yes, TC39 strawman: http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
18:05
<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.
18:06
<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
18:06
<scott_gonzalez>
Perhaps I can bug some Mozilla devs to make it high priority :-)
18:07
<Ms2ger>
Good luck with that, they need to get a phone shipped
18:07
<scott_gonzalez>
Though it seems to make sense to have TC39 standardize Error.stack first.
18:08
<Hixie>
currently the feedback on this topic is from May, and the oldest feedback i have to deal with is from 2009.
18:08
<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
18:08
<Hixie>
so about 4 months behind the onerror thing
18:08
<Hixie>
so not too bad
18:09
<scott_gonzalez>
Do you have an approximate burn rate on the backlog?
18:10
<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.
18:10
<Hixie>
months
18:10
<scott_gonzalez>
ok
18:11
<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.
18:11
<Hixie>
my main current task is to make this better, fwiw :-)
18:11
<Hixie>
(leaving w3c being a huge part of that)
18:12
<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)
18:13
<Hixie>
hey, it's mr jennings!
18:15
<cullenjennings>
drop in now and then for a breath of fresh air from the usual cesspools I hand out in :-)
18:15
<Hixie>
this is pretty cesspooly too :-P
18:15
<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.
18:16
<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
18:16
<Hixie>
scott_gonzalez: (if there's some way i can hook into it, that'd be awesome)
18:16
<Hixie>
scott_gonzalez: (e.g. keeping it non-exception-specific)
18:17
<scott_gonzalez>
You'll need something for compile errors which don't have Error objects, correct?
18:18
<Hixie>
well compile errors probabyl don't have stacks
18:18
<Hixie>
though come to think of it, maybe only exceptions will ever have stacks, in onerror
18:18
<Hixie>
in which case it's fine, i just need a way to get the stack out of the unhandled exception object
18:18
<Hixie>
or just expose that object
18:19
<Hixie>
which would imho be even more ideal
18:36
<MikeSmith>
btw http://platform.html5.org/specs/
18:36
<Ms2ger>
Ooh, it looks different
18:37
<Hixie>
it's artificially inflated by listing all the HTML sections as separate specs :-)
18:37
<Hixie>
(e.g. workers and storage)
18:38
<Ms2ger>
Otherwise it's artificially inflated by you sticking everything in one spec ;)
18:55
<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
18:57
<zewt>
(at least I know I don't have to search @whatwg ... heh)
18:58
<Ms2ger>
IETF somewhere, I think
18:58
<zewt>
maybe there too, I'm not on any ietf lists
19:00
<Ms2ger>
I'd look, but http://mail.apps.ietf.org seems down
19:01
<zewt>
can I shoot the w3 bug tracker into the sun, between blocking search engines and not including email addresses on comments
19:01
<zewt>
2012 and I can't do a simple "site:w3.org/Bugs microsoft.com" search
19:03
<Hixie>
if you log in it includes e-mail addresses
19:05
<Ms2ger>
http://comments.gmane.org/gmane.ietf.charsets/578
19:05
<Ms2ger>
zewt, ^
19:07
<zewt>
what an amusingly terrible email archive viewer, heh :P
19:07
<Ms2ger>
It's slightly better than "Unable to connect" :)
19:08
<zewt>
(it's the "Continue reading" thing that makes it seem terrible to me, incidentally)
19:08
<Ms2ger>
Oh, I hadn't even seen that
19:09
<zewt>
I missed it on the first couple mails, until one came up that was more obviously truncated
19:10
<Hixie>
TabAtkins: ok, i sent my reply, you can send your srcset feedback without making my life hard :-P
19:11
<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
19:11
<zewt>
"use unicode", as if the existing web with millions of non-unicode pages somehow doesn't exist
19:12
<Ms2ger>
It's not clear to me that guy works on IE
19:13
<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.
19:13
<Hixie>
oh and two mailman bounce notifications
19:14
<Hixie>
bbl. lunch.
19:14
<Ms2ger>
No wonder you've got a lot of unread email
19:17
<TabAtkins>
Hixie: Do you end up bccing everyone who you crafted your megaemails from?
19:17
<TabAtkins>
I'm trying to figure out why your megaemails don't get the whatwg label.
19:19
<zewt>
TabAtkins: i'm not even sure what the list() gmail filter/search criteria matches against
19:19
<TabAtkins>
I have no clue.
19:20
<Ms2ger>
I assume the List-Id: Public mailing list for the WHAT working group <whatwg-whatwg.org>
19:21
<zewt>
gmail fail: the "show original" dropdown menu item isn't a functional link, so I can't middle-click it into another window
19:22
<zewt>
yearning for the days when google pages were actually a good model for others to follow
19:22
<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
19:23
<zewt>
maybe because I opened the mail before receiving the list version, or something
19:23
<TabAtkins>
Possibly, I guess. My experience with its deduping is pretty good.
19:23
<zewt>
(presumably this 250 gigabyte email takes longer to be distributed than most)
19:23
<Wilto>
Hixie: Are you still winding your way through the respimg threads?
19:24
<zewt>
"mucking" might be an appropriate verb
19:25
<Wilto>
You ain’t wrong, zewt.
19:26
<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.
19:27
<zewt>
quotostrophes!
19:28
<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
19:28
<zewt>
by a staggering margin
19:29
<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.
19:30
<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.
19:30
TabAtkins
prepares a new email missive.
19:30
<Wilto>
I am afraid to ask.
19:31
<TabAtkins>
Hey, it only takes one more email to move you to an island. I'll just nudge you. ^_^
19:31
<Wilto>
I get that a lot.
19:32
<zewt>
the whole thing had the feel of a petition
19:32
<zewt>
"let's get all of our friends to join up and make some noise! show our rage!"
19:32
<Wilto>
Yeah. Honestly, I take the blame for that.
19:33
<Wilto>
I forget who it was, but being asked to furnish “proof” of developer sentiment between the two pattens set me off.
19:34
<Hixie>
TabAtkins: yes, i usually bcc anyone who wrote the mail, in case they've since unsubscribed
19:34
<Hixie>
TabAtkins: (and gmail randomly picks one to dedupe)
19:34
<zewt>
has "developer sentiment" ever trumped technical arguments or use cases? heh
19:34
<TabAtkins>
Okay. I'll amend my filter to catch these.
19:35
<Wilto>
zewt: Nope, just one piece of a very large puzzle.
19:35
<zewt>
am I weird for writing css rules like "#foo #bar" where #foo is basically a comment
19:35
<Hixie>
Wilto: just sent a reply to the last 340 e-mails on that thread in the whatwg
19:35
<zewt>
heh
19:35
<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)
19:35
<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.
19:36
<zewt>
(when in the English language history did "compromise" become a positive word?)
19:36
<Wilto>
…You’re saying you didn’t catch anything about values other than pixels?
19:36
<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.
19:36
<zewt>
"compromise your principles" and "a security compromise" became "you have to compromise!"
19:37
<Hixie>
Wilto: there were some discussions about non-pixel things but they weren't anything new. i did respond to those though.
19:37
<Hixie>
zewt: yeah, i actually mentioned that in my e-mail just now :-)
19:37
<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?
19:37
<Wilto>
Oh, here we are—sorry. Reading.
19:37
<Hixie>
zooming also zooms px
19:38
<Wilto>
…Pixel-based media queries are not reevaulated on page zoom.
19:38
<Wilto>
Em-based media queries are, according to the recalculated root font size.
19:38
<Wilto>
16px by default, but changes with zoom.
19:39
<Wilto>
As such, the layout will be reevaluates as the user zooms in and out.
19:39
<Hixie>
you are either wrong, or confusing page zoom with default text size
19:39
<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.
19:39
<Wilto>
http://blog.cloudfour.com/
19:39
<Wilto>
Zoom in on that multiple times. You’re in Chrome I assume, so you’ll need to refresh for the layout to change.
19:39
<Hixie>
anyway, i have to run to lunch -- if there's new information, send it to the list :-)
19:39
<Hixie>
(but please read the e-mail i sent first!)
19:39
<Wilto>
—you’re kidding me.
19:39
<Hixie>
bbl
19:41
<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)
19:41
<zewt>
(i'll grant that as a web author, i hate people like me)
19:42
<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.
19:42
<Wilto>
All the benefits of zooming, without the broken layout.
19:43
<Wilto>
It’s brilliant, and crazy easy to implement.
19:43
<Wilto>
To author, rather.
19:45
<Wilto>
When using ems to determine source images, we could ensure that the images remain layout-appropriate.
19:46
<Wilto>
Or at the very least, less-blurry.
19:52
<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.
19:52
<jgraham>
Wilto: It might be more convincing if you could point to spec text rather than blog entries
19:52
<Wilto>
Or author some.
19:53
<Wilto>
http://www.w3.org/TR/css3-mediaqueries/#units
19:53
<zewt>
there's no querySelector() for matching up the ancestor list rather than down? :|
19:54
<Wilto>
In modern browsers, initial font-size is increased or decreased — at varying increments, depending on the browser — with zoom.
19:54
<Wilto>
jgraham: And with all due respect, I’m not presenting an argument. This is how em-based media queries work, full stop.
19:54
<Wilto>
I invite anyone involved to prove me wrong.
19:55
<jgraham>
Wilto: I'm not suggesting that it is an argument
19:55
<Wilto>
Let me rephrase, then.
19:55
<jgraham>
I'm suggesting the right citation for behaviour is spec text
19:55
<Wilto>
I’m not trying to be “convincing.”
19:55
<jgraham>
Not blog posts
19:55
<Wilto>
I cited a live example, at first.
19:55
<jgraham>
(unless you are claiming that browsers violate the spec, in which case the correct citation is test cases)
19:56
<Wilto>
In use on a production website, and supported in every major browser.
19:56
Ms2ger
yawns
19:56
<zewt>
and no call to ask if an element matches a selector, without traversing children? :|
19:57
<Ms2ger>
.mozMatchesSelector()?
19:57
<zewt>
primary audience is webkit, heh
19:58
<zewt>
(was looking for the latter to implement the former myself, eg. searching up the tree)
19:58
<TabAtkins>
zewt: Yeah, jQuery's .closest() function is *ridiculously* useful.
19:58
<zewt>
(... without having to pull in jQuery or prototype)
19:58
<zewt>
prototype has .up(), iirc (been a while since I've used it)
19:59
<jgraham>
(media queries is a terribly written spec)
20:00
<zewt>
guess there's webkitMatchesSelector too
20:00
<TabAtkins>
Polyfill *MatchesSelector, then do "while(!el.matchesSelector('foo')) { el = el.parentNode; }" for now.
20:00
<zewt>
yeah, started on that already :)
20:01
<zewt>
(well, not sure yet if I'll polyfill it if it's missing entirely; need to check who supports it first)
20:16
<gsnedders>
Lone surrogates are the bane of my existance.
20:16
<zewt>
heh
20:17
<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
20:18
<gsnedders>
The problem is Python nowadays rejects invalid UTF-8 sequences, inc. those with surrogates.
20:47
<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
20:47
<zewt>
(short of creating the img entirely programmatically, which I'd prefer not to do)
20:51
<TabAtkins>
Use a data for an empty png
20:51
<TabAtkins>
data: url, rather.
20:56
<gsnedders>
Is there any character encoding that Python supports that allows lone surrogates?
20:56
gsnedders
is on tethered 2G connection, so…
21:15
<zewt>
dumping a line of copied-and-pasted gibberish into HTML source seems like an unfortunate thing for validators to encourage, heh
21:19
<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)
21:37
<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?
21:39
<TabAtkins>
Yes, 96px = 1in, forever.
21:39
<TabAtkins>
If you're wondering why, blame everyone who mixes px and pt and expects a constant ratio or else their layouts break.
21:41
<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
21:41
<Hixie>
chriseppstein: yes
21:42
<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?
21:42
<Hixie>
chriseppstein: 1px = 0.264583mm = 0.010416in = 1.333pt
21:43
<TabAtkins>
chriseppstein: Yes, on all devices, everywhere, forever.
21:43
<Hixie>
where px = CSS pixels, mm = CSS millimeters, in = CSS inches, and pt = CSS points
21:43
<Hixie>
and they have nothing to do with real pixels, real millimeters, real inches, or real points
21:43
<chriseppstein>
I love CSS
21:43
<Hixie>
(except that on most displays, 1 CSS pixel maps to 1 device pixel, if the user hasn't zoomed)
21:43
<TabAtkins>
Again, it's to support a lot of legacy content engineered for screens that were (or pretended to be) 96dpi.
21:44
<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
21:44
<chriseppstein>
Ah I see. it's because CSS inch isn't actually a ruler inch?
21:45
<Hixie>
right
21:45
<Hixie>
it's 96 pixels
21:45
<chriseppstein>
omg
21:45
<Hixie>
CSS pixels
21:45
<chriseppstein>
Ok. I get it now
21:45
<chriseppstein>
thank you
21:45
<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)
21:46
<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.
21:46
<TabAtkins>
Depending on how close you are to an integer multiple of 96dpi.
21:46
<Hixie>
and that's assuming you're not zooming
21:47
<TabAtkins>
Yeah, at normal zoom.
21:47
<Hixie>
nor on a projector, as zewt says :-)
21:47
<chriseppstein>
You had me at 1in != 1in
21:47
<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.
21:47
<Hixie>
1in != 1"
21:47
<chriseppstein>
that
21:48
<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.
21:48
<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.)
21:49
<zewt>
help @ artist giving me a PSD site mockup with embossed text in buttons
21:50
<TabAtkins>
zewt: text-shadow is your friend, if you want to match that.
21:50
<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)
21:51
<zewt>
(of course I could probably drop it and nobody would noticed, but I'll give it a shot)
21:51
<zewt>
also notice
21:57
<chriseppstein>
TabAtkins: while I'm here, I've been making a patch for calc() support in sass
21:57
<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
21:58
<TabAtkins>
Yes. The spec is CR, so prefixes will drop soonish.
21:59
<chriseppstein>
lovely
21:59
<chriseppstein>
who supports it unprefixed right now?
22:02
<TabAtkins>
dunno!
22:02
<chriseppstein>
i'll look it up. thanks
23:06
<Hixie>
so... http://www.ietf.org/mail-archive/web/ietf-types/current/msg01719.html tell me again why "stability" is a good thing?
23:07
<hober>
Hixie: that email is amazing.
23:08
<zewt>
Hixie: s/stability/ietf/
23:20
<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?
23:21
<Hixie>
oh, right, probably too big
23:21
<Hixie>
thanks for pointing that out
23:21
<Hixie>
i was wondering why nobody had replied...
23:22
<Hixie>
that's weird, my message is in the queue twice
23:23
<Hixie>
ok should be sent now
23:23
<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
23:23
<Hixie>
if anyone wants to review that, please do let me know if you see any issues
23:34
<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
23:34
<Hixie>
haven't had this low number of pending e-mails since 2010, woot