| 00:05 | <uf0> | ok so.. i'm going to give an example: |
| 00:05 | <uf0> | say I'm creating a header in HTML5 |
| 00:05 | <uf0> | I would obviously put anything relating to that in <header> |
| 00:05 | <uf0> | my question does <nav> go in <header> |
| 00:05 | <uf0> | or outside seperately |
| 00:06 | <uf0> | now usually in my days now |
| 00:06 | <uf0> | i would put a <ul class="nav"> inside the <div id="header"> |
| 00:06 | <uf0> | thoughts? |
| 00:06 | <hober> | either way dude |
| 00:06 | <Hixie> | putting <nav> in <header> is fine, yeah |
| 00:07 | <uf0> | cool |
| 00:07 | <uf0> | another question, in my olden days i would have a <div id="wrap"> to hold the header, footer and content |
| 00:07 | <uf0> | is that now a <section id="wrap"> |
| 00:07 | <uf0> | or still a div |
| 00:07 | <hober> | that's what <body>'s for |
| 00:08 | <uf0> | no hober |
| 00:08 | <hober> | but, if you need an extraneous element for whatever reason, keep on trucking with <div> there. |
| 00:08 | <uf0> | to wrap and do a margin auto with a width, I don't do that in body |
| 00:08 | <uf0> | or <body> |
| 00:08 | <uf0> | i always have a container for that |
| 00:08 | <hober> | body { width:30em; margin: 0 auto; } works fine |
| 00:08 | <uf0> | so I'm wondering if <section> is the right tag |
| 00:08 | <hober> | I do that all the time |
| 00:09 | <uf0> | I disagree with that, though it technically works |
| 00:09 | <hober> | well, anyway, if you must have a single child of body, <div> is the correct element |
| 00:09 | <hober> | <section> implies you're trying to impact the outline algorithm, which is weird in this case |
| 00:09 | <uf0> | alright |
| 00:11 | <uf0> | thx Hixie/hober |
| 00:11 | <hober> | np |
| 00:11 | <Hixie> | np |
| 00:11 | <Hixie> | hober's right on the <div> thing |
| 00:11 | <Hixie> | don't forget you can style <html> and <body> separately, though |
| 00:12 | <Hixie> | so you often don't need a <div> as well |
| 00:42 | <uf0> | this is probably a dumb question, but what's the difference between W3C and WHATWG? |
| 00:42 | <uf0> | do you guys work seperately or together |
| 00:43 | <uf0> | i don't get it |
| 00:43 | <Hixie> | together |
| 00:43 | <Hixie> | whatwg started working on html back in 2003/4 when the w3c didn't want to work on html any more, and when they changed their mind we started working together |
| 00:43 | <uf0> | who decides what's approved? |
| 00:43 | <uf0> | you guys or them |
| 00:44 | <zewt> | W:DWG |
| 00:45 | <Hixie> | uf0: neither |
| 00:45 | <uf0> | oh |
| 00:45 | <Hixie> | uf0: the browser vendors decide |
| 00:45 | <AryehGregor> | uf0, the WHATWG and W3C have different specs. The WHATWG decides what goes into its spec, the W3C decides what goes into its spec. |
| 00:45 | <AryehGregor> | Hixie, not for authoring conformance and non-normative material! |
| 00:45 | <uf0> | scratches head*** |
| 00:46 | <uf0> | so what spec do I use w3c or whatwg |
| 00:46 | <AryehGregor> | They're almost the same, except the W3C one leaves out some stuff and is split up more. |
| 00:46 | <Hixie> | yeah, for authoring conformance criteria the issue is a bit more murky -- in practice it seems the w3c decides those, we've just made the whatwg spec match whatever they do |
| 00:46 | <jamesr_> | if you are a web author i'd recommend using the WHATWG spec |
| 00:46 | <AryehGregor> | Clearly, the people here are mostly going to recommend the WHATWG spec. |
| 00:46 | <Hixie> | for non-normative material they tend to differ a little more |
| 00:46 | <AryehGregor> | Since this is #whatwg. :) |
| 00:47 | <AryehGregor> | It has useful stuff like implementation status annotations. |
| 00:47 | <AryehGregor> | And a comment box everywhere instead of just the front. |
| 00:47 | <AryehGregor> | (although that gets in the way when using Ctrl-F on Firefox) |
| 00:48 | <Hixie> | you can close the comment box |
| 00:48 | <uf0> | hmm ok |
| 00:48 | <Hixie> | click the arrow :-) |
| 00:48 | <zewt> | pages that eat ^F make me want to punch the html :P |
| 00:48 | <AryehGregor> | But then I have to click again later to open it. :( |
| 00:48 | <Hixie> | uf0: the whatwg spec has some text at the top that discusses this btw |
| 00:48 | <Hixie> | uf0: http://whatwg.org/html in the intro sectiuon |
| 00:49 | <AryehGregor> | I have noticed that Firefox's behavior is nicer than Chrome's in that if you hit the end and wrap around, it's instantly noticeable because the search term is now at the top of the page instead of the bottom. |
| 00:49 | <AryehGregor> | Whereas with Chrome I often find myself cycling through all the possibilities repeatedly and not noticing. |
| 00:49 | <Hixie> | the main problem with chrome's find in page is that every few searches it decides to go out to lunch |
| 00:50 | <webr3> | uf0, lol - I'm currently arguing on the mailing lists that both the w3c and the what wg don't actually provide a spec for the likes of you and me - so quiet funny timing - the closest you've got is http://caniuse.com/ |
| 00:51 | <webr3> | s/quiet/quite |
| 00:51 | <AryehGregor> | Yeah, the official spec is realistically not ever going to be the best thing for typical authors. |
| 00:51 | <AryehGregor> | They're way too precise, i.e., long-winded and incomprehensible. |
| 00:51 | <Hixie> | ben is working on developers.whatwg.org which may be helpful |
| 00:52 | <Hixie> | lachlan used to work on a tutorial spec, but dunno what's happened with that |
| 00:52 | <Hixie> | haven't seen lachy in a while, in fact. anyone know if he's still around? |
| 00:52 | <AryehGregor> | Hmm, dunno. |
| 01:07 | <hober> | he's still at opera afaicr |
| 01:11 | <AryehGregor> | jgraham, you need better stringification for expected/actual reporting. If the expected value is, e.g., the empty string, it's kind of hard to read. And you can't tell null from "null" and so on. May I recommend: http://dvcs.w3.org/hg/html/file/tip/tests/submission/AryehGregor/reflection/original-harness.js#l16 |
| 01:11 | <AryehGregor> | Actually, line number or filename may change, so a specific revision is better: http://dvcs.w3.org/hg/html/file/f86e2b4137f7/tests/submission/AryehGregor/reflection/original-harness.js#l16 |
| 01:17 | <AryehGregor> | Okay, IE9 RC fails every single test, totally legitimately. |
| 01:17 | <AryehGregor> | Opera fails almost all. |
| 01:17 | <AryehGregor> | Mostly because of not handling nulls correctly. |
| 01:17 | <AryehGregor> | WebKit and Gecko pass some. |
| 01:18 | <AryehGregor> | They seem to have no bugs in their string reflection that I've found, sadly. |
| 01:18 | <AryehGregor> | If I do find, I'll make sure to make them fail too. :) |
| 01:18 | <AryehGregor> | But first I'll make Opera fail the remaining few tests by making sure to add strings with binary for everything. |
| 01:18 | <AryehGregor> | But that's for tomorrow. |
| 01:27 | <AryehGregor> | HTML test mail sent. Yay. |
| 01:27 | AryehGregor | is off for the night |
| 08:28 | <jgraham> | AryehGregor: Yes, better stringification seems like a good idea. |
| 08:29 | <jgraham> | Also, there is no need to make Opera fail all your tests just because :) |
| 08:30 | <jgraham> | Well specifically it's not clear that setting things up so that one bug causes everything to fail is that useful, since it will have the effect of hiding more significant bugs |
| 08:30 | <jgraham> | Although I do of course agree that we should fix the null-handling issues |
| 08:40 | <annevk> | Hixie, regarding the stability of DOM Core; I would say it is pretty stable but we are planning a number of experiments that make a few specific parts "less stable" |
| 08:40 | <annevk> | Hixie, i.e. killing the concept of Attr being a node |
| 08:40 | <Hixie> | it's not really stableness i'm worried about so much as completeness |
| 08:41 | <Hixie> | last i saw it, it was extremely incomplete |
| 08:41 | <annevk> | really? |
| 08:41 | <Hixie> | well last i saw it was months ago :-) |
| 08:41 | <annevk> | the Nodes part has not changed much since publication |
| 08:41 | <Hixie> | what's the url these days? |
| 08:42 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html |
| 08:43 | <jgraham> | annevk: I am like 90% sure that Closure relies on the nodeness of Attr |
| 08:43 | <jgraham> | If it doesn't, it does a very good job of faking it |
| 08:43 | <Hixie> | ok well step one will have to be me going very carefully through the definitions to make sure i didn't change any since the text was copied |
| 08:43 | <jgraham> | So I think we already lost there |
| 08:44 | jgraham | would be happy to be proven wrong |
| 08:44 | <annevk> | jgraham, I'm sure some stuff will break, we'll have to figure out how much we can battle it with alpha builds |
| 08:44 | <jgraham> | If some stuff === most Google properties, we have a problem |
| 08:44 | <Hixie> | oh wow, this definition of Event is so much better than I'm used to. |
| 08:46 | <jgraham> | http://www.google.com/codesearch?q=getAttributeNode+package%3Ahttp%3A%2F%2Fclosure-library\.googlecode\.com&origq=getAttributeNode&btnG=Search+Trunk |
| 08:46 | <Hixie> | annevk: yeah, wow, this is way more complete than the last time i saw it |
| 08:46 | <Hixie> | annevk: this is awesometastic |
| 08:47 | <Hixie> | annevk++ Ms2ger++ |
| 08:47 | <annevk> | :) |
| 08:47 | <Hixie> | k well i guess it's time to start moving to that draft |
| 08:48 | <Hixie> | this is so much more readable than dom3 core |
| 08:54 | <Hixie> | annevk: filed bug 12094 on switching to web dom core |
| 08:55 | <Hixie> | annevk: when i do it i'll go through the definitions carefully and any that are identical and make more sense in dom core i'll just reference dom core -- please let me know if you ever change those definitions since they can have really drastic ramifications |
| 08:56 | <annevk> | Hixie, yeah, pretty sure Ms2ger and I can keep on top of that |
| 08:56 | <annevk> | Hixie, we have for exceptions at least :) |
| 08:56 | <Hixie> | cool :-) |
| 08:57 | <Hixie> | seeing how web dome core has matured really made my day :-) |
| 08:57 | <Hixie> | web dom core, even |
| 08:59 | <zcorpan> | annevk: time for a publication heartbeat for web dom core? |
| 09:01 | <annevk> | zcorpan, that is the plan yes, before I leave :) |
| 09:02 | <annevk> | I want to fix the issues with events smaug pointed out I think |
| 09:02 | <zcorpan> | cool |
| 09:03 | <annevk> | http://irinawerning.com/back-to-the-fut/back-to-the-future/ is pretty amazing |
| 09:15 | <annevk> | Hixie, I thought readonly meant something like is disabled but is submitted |
| 09:15 | <Hixie> | readonly means "interactive but not mutable" |
| 09:15 | <Hixie> | it also as a side-effect is submitted when disabled is not |
| 09:15 | <Hixie> | but that's more of a historical artefact |
| 09:16 | <Hixie> | readonly just comes from the fact that UI toolkits for text fields have this "readonly" state separate from the disabled state |
| 09:16 | <annevk> | mkay |
| 09:16 | <Hixie> | so when browsers first did this, it made sense to add readonly for text fields |
| 09:18 | <Hixie> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=11483#c1 <-- damnit. :-P |
| 09:27 | <Hixie> | annevk: re http://www.w3.org/Bugs/Public/show_bug.cgi?id=11452, it would be helpful if you could make a list of all the ways that rfc2388 is problematic -- that would give me cover to just go and respec it from scratch |
| 09:27 | <Hixie> | annevk: if i just do it people will go ballistic as usual about how we're ignoring standards, and it would be good to have an explanation of the problems |
| 09:27 | <Hixie> | annevk: (it would also allow me to approach larry and ask him if he's willing to fix the spec first) |
| 09:31 | <annevk> | be great if he could do that; I'll give it a shot |
| 09:35 | <phrearch> | hello |
| 09:35 | <phrearch> | do websockets keep track of message ids themselves? |
| 09:35 | <phrearch> | i got some sync problems |
| 09:39 | <jgraham> | phrearch: message ids? |
| 09:41 | <phrearch> | well, i got two messages firing now at the moment: one to get online users, and one to sync a canvas painting app. Both arrive in this jquery websocket router: http://paste.pocoo.org/show/339478/ |
| 09:42 | <phrearch> | the callback is fired twice somehow, so i thought i maybe have to queue the messages and match them on origin |
| 09:42 | <phrearch> | if a message comes in, i would like to be able which event fired it |
| 09:43 | <phrearch> | i started with jsonrpc which had a message id in it, but removed that(it had a function i guess :) ) |
| 09:43 | <hsivonen> | someone should make "Wikipedia > IANA" t-shirts |
| 09:44 | <phrearch> | so, i was wondering if the websocket api has a way to find out which message belongs to which call |
| 09:44 | <phrearch> | or do i have to add the message id manually again |
| 09:44 | <Hixie> | hsivonen: and you say _I'm_ unnecessarily antagonistic. :-P |
| 09:44 | <hsivonen> | Hixie: :-) |
| 09:45 | <phrearch> | having a 36 char uuid in there seems not to be good for small message parsing |
| 09:47 | <zcorpan> | what happened to https://bitbucket.org/ms2ger/web-dom-core/ ? |
| 09:53 | <jgraham> | phrearch: I'm not quite sure I follow. In general if you have a DOM event you can work out what type of event it is. But if you have two message events, the API doesn't provide any unique identifier for each; you hvae to do that at the application ("subprotocol") level |
| 09:53 | <annevk> | zcorpan, bitbucket does not redirect :/ https://bitbucket.org/ms2ger/dom-core/ |
| 09:53 | <phrearch> | jgraham: i was already affraid for that :) |
| 09:54 | <jgraham> | phrearch: Well it's not clear to me what it would provide |
| 09:55 | <phrearch> | hm, i hoped for some id in the send message thats linked to the message event |
| 09:55 | <jgraham> | s/would/could/ |
| 09:55 | <phrearch> | but it can be done in the application indeed |
| 09:56 | <jgraham> | What do you mean "linked to the message event"? |
| 09:56 | <jgraham> | You mean the DOM event object? |
| 09:56 | <jgraham> | or something different? |
| 09:56 | <phrearch> | yea, i dont know if thats even possible but |
| 09:56 | <zcorpan> | annevk: ah |
| 09:57 | <annevk> | zcorpan, also it did not advertise that changing the name changes the URL |
| 09:57 | <annevk> | should I change it back? |
| 09:58 | <zcorpan> | naw it's ok |
| 09:58 | <jgraham> | phrearch: Well as long as you are entirely on the client, the message is already bound to the event object |
| 09:58 | <jgraham> | Since it is e.data that contains the message |
| 09:58 | <jgraham> | But I guess you don't mean that |
| 09:59 | <phrearch> | yea, thats what i meant |
| 09:59 | <phrearch> | i think i got it. in the message object, i can see the original calling function in .target.origin |
| 10:00 | <phrearch> | or not...hm, ill see if i can fix it like this first |
| 10:08 | <phrearch> | hm, any idea why origin sometimes is overwritten with two subsequent ws messages? http://paste.pocoo.org/show/339489/ |
| 10:08 | <phrearch> | two origins should be different, but most of the times they are the same |
| 10:11 | <annevk> | whoa |
| 10:11 | <annevk> | constructive feedback from Jukka Korpela on the WHATWG list |
| 10:13 | <Hixie> | ok bed time |
| 11:01 | <jgraham> | So I started an infrastructure requirements page for the HTML test task force: http://www.w3.org/html/wg/wiki/Testing/Infrastructure/Requirements/ |
| 11:01 | <jgraham> | Comments before I send it to the list? |
| 11:02 | jgraham | realises most relevant people are asleep |
| 11:04 | jgraham | wonders if there is a good code review tool for hg |
| 11:17 | <phrearch> | ok problem solved :) |
| 11:23 | <Philip`> | "Most test review is currently done informally via the mailing list. This doesn't work so well, especially for for large testsuites. Maybe there is an existing tool that can help us here." |
| 11:23 | <Philip`> | Is the problem the lack of tools, or is it primarily the lack of people? |
| 11:24 | <jgraham> | Pass |
| 11:24 | <jgraham> | But I don't really fancy reviewing, say, AryehGregor's tests without some way to write inline comments |
| 11:24 | <jgraham> | And we don't really have a good way of knowing what has/hasn't been reviewed |
| 11:25 | <jgraham> | So the tools might not save us, but they could help us |
| 11:34 | <matjas> | Warning: imap_open() [function.imap-open]: Couldn't open stream {imap.gmail.com:993/imap/ssl}INBOX in /f2/xanthir/public/feed/public-css-commits/index.php on line 22 |
| 11:34 | <matjas> | can't connect: TLS/SSL failure for imap.gmail.com: SSL negotiation failed |
| 11:34 | <matjas> | TabAtkins: ^ |
| 11:36 | <matjas> | TabAtkins: Been getting a lot of errors (timeouts/PHP errors) on your CSS feed lately. |
| 11:39 | <karlcow> | thanks annevk for the link http://irinawerning.com/back-to-the-fut/back-to-the-future/ Wonderful. Shadows of time, ambiguity of self. |
| 11:41 | <jgraham> | Yeah, I rather enjoyed those |
| 12:02 | <karlcow> | http://www.youtube.com/watch?v=64TcBiqmVko |
| 12:02 | <karlcow> | WegGL aquarium using a few computers |
| 12:03 | <karlcow> | (and cheesy music) |
| 12:46 | <annevk> | for anyone who is slightly bored, check archives of w3c-css-wg ;) |
| 13:03 | <annevk> | bah |
| 13:03 | <annevk> | per Wikipedia objects in a tree structure are called nodes |
| 13:03 | <annevk> | nice conflict there with the DOM! |
| 13:03 | <hsivonen> | what's the conflict? |
| 13:04 | <zcorpan> | IndexedDB doesn't have DOM nodes, but has a tree structure (at least i think it does?) |
| 13:04 | <annevk> | apparently DOM Events is used in Indexed DB on a non-DOM tree structure |
| 13:05 | <annevk> | so I need to define the concept of "tree structure" and then map the Nodes Model to it |
| 13:05 | <annevk> | and indexed DB will need to map its own model to it |
| 13:05 | <annevk> | well, that's my vague plan and I'm not getting very far |
| 13:05 | <annevk> | like, can I just say "tree structure" and expect it to be clear? |
| 13:08 | <jgraham> | annevk: Well yes, they're called Nodes in DOM because DOM is a tree and trees have nodes |
| 13:08 | <annevk> | anyone an idea how to include a subtle reference to /r/trees ? |
| 13:09 | <jgraham> | I think you just blew subtle |
| 13:09 | <annevk> | jgraham, thank you captain obvious :p |
| 13:10 | <jgraham> | annevk: Anyway the event nodes thing shouldn't be too hard. You just need to define that they operate on an abstract tree and that they move between nodes in that tree in the required way |
| 13:11 | <jgraham> | And explicitly say that node !== DOM Node |
| 13:11 | <jgraham> | But that DOM Nodes do map onto the abstract nodes |
| 13:11 | <annevk> | yeah, something like that |
| 13:12 | <annevk> | I guess I should just take a stab at it |
| 13:13 | <jgraham> | (the only other thing I can think to do is to use the word "vertex" which is more general but probably more confusing) |
| 13:16 | <karlcow> | Spring rain |
| 13:16 | <karlcow> | conveyed under the trees |
| 13:16 | <karlcow> | in drops. |
| 13:16 | <karlcow> | — Basho |
| 13:16 | <karlcow> | hmm maybe not helpful for annevk |
| 13:17 | karlcow | had to search for r-tree http://en.wikipedia.org/wiki/R-tree |
| 13:20 | Philip` | can't remember ever hearing people use "vertex" in the context of trees |
| 13:21 | <Philip`> | (Only in unconstrainted graphs) |
| 13:21 | <Philip`> | s/ted/ed/ |
| 13:21 | <karlcow> | Philip`: http://en.wikipedia.org/wiki/Tree_(graph_theory) |
| 13:22 | <annevk> | http://en.wikipedia.org/wiki/Tree_structure is the more useful one |
| 13:22 | <karlcow> | it seems to be mentioned here |
| 13:23 | Philip` | can't remember often hearing people use "tree" in the context of undirected graphs |
| 13:23 | <karlcow> | http://en.wikipedia.org/wiki/Vertex_(graph_theory) |
| 13:23 | <Philip`> | (probably because I'm in more contact with computer scientists than graph theorists) |
| 13:24 | <karlcow> | and my own understanding of vertex is more http://en.wikipedia.org/wiki/Vertex_(physics) |
| 13:25 | <karlcow> | as well as http://en.wikipedia.org/wiki/Vertex_model |
| 13:26 | <zcorpan> | annevk: window is part of the event tree but isn't a DOM node |
| 13:26 | <zcorpan> | annevk: so it's not a new problem with indexeddb |
| 13:27 | <annevk> | zcorpan, the way Hixie defined Window it's still not really part of the event tree |
| 13:27 | <annevk> | it just participates in event dispatching |
| 13:28 | <zcorpan> | i thought all bubbling events bubbled up to window |
| 13:28 | <zcorpan> | no? |
| 13:29 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#events-and-the-window-object |
| 13:30 | <zcorpan> | what's the difference between that and being part of the tree? |
| 13:30 | <annevk> | it's conceptually different |
| 13:31 | <annevk> | anyway, I'm working on an abstract definition of "Trees" |
| 13:31 | <zcorpan> | why is 'load' excluded btw? when is a load event fired on document? |
| 13:32 | <zcorpan> | or, oh |
| 13:32 | <zcorpan> | hmm |
| 13:35 | <zcorpan> | is it just to prevent capturing 'load' listeners on window to run for <img> loads? or why? |
| 13:42 | <annevk> | legacy |
| 13:58 | <annevk> | made modest progress |
| 14:22 | <annevk> | I think I fixed it |
| 14:23 | <annevk> | though "Common infrastructure" is still somewhat messy imo |
| 14:23 | <annevk> | it has copy and paste all over it |
| 14:25 | <karlcow> | do Firefox, Chrome, IE and Safari send a different HTTP Code depending on the payload size of an HTTP POST |
| 14:25 | <karlcow> | Expect: 100-continue for bigger payloads? |
| 14:37 | <annevk> | I guess Hixie's "Common infrastructure" is also somewhat organized adhoc |
| 14:37 | <annevk> | I've no idea why Conformance would be in there for instance |
| 14:37 | <karlcow> | http://groups.google.com/group/mozilla.feedback.firefox/browse_thread/thread/8918bae4308e476d?tvc=2 |
| 14:37 | annevk | hopes more people care about this and can give some insight |
| 14:38 | <annevk> | oh great, in XHR Terminology is a subsection of Conformance! |
| 14:38 | <karlcow> | annevk: what do you refer to? link? |
| 14:38 | <annevk> | and nobody complaints |
| 14:38 | <annevk> | bah, no rules |
| 14:39 | <annevk> | karlcow, load e.g. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html and http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ and maybe the HTML spec and compare how they organize the initial sections |
| 14:39 | <annevk> | CORS follows XHR http://dev.w3.org/2006/waf/access-control/ |
| 14:39 | <karlcow> | checking |
| 14:40 | <annevk> | I'm leaning towards grouping conformance/extensibility/dependency under "Conformance" and the rest under "Terminology" both separate top-level sections |
| 14:40 | <annevk> | for all specs I edit |
| 14:40 | <annevk> | "Conformance" first |
| 14:40 | <karlcow> | indeed terminology under conformance seems strange |
| 14:41 | <karlcow> | fixable |
| 14:42 | <annevk> | oh sure, I just never quite know how and what patterns to follow |
| 14:42 | <annevk> | but there's hardly any spec writing pattern I guess when you think most specs out there are crappy :p |
| 14:43 | <karlcow> | Common infrastructure is a strange name in http://dev.w3.org/html5/spec/ but I guess I didn't really pay attention to it |
| 14:44 | <karlcow> | annevk: from experience, each time we tried to create editing patterns, a NIH syndrome arised. Each editor being a geek came up with his own software/technique/tool to do things :) |
| 14:44 | <annevk> | that's exactly what's happening here |
| 14:45 | <annevk> | but I mean, putting Terminology under Introduction like in XML? |
| 14:46 | <annevk> | terminology is overall a pretty crappy section; ideally it's not there |
| 14:47 | <annevk> | you want to introduce terms as the reader reads through the spec |
| 14:47 | <annevk> | not upfront somewhere, that never really works well |
| 14:47 | <hsivonen> | terminology up front is so ISO |
| 14:47 | <karlcow> | what we did in QA framework spec http://www.w3.org/TR/qaframe-spec/ is that. We introduced terms and made a glossary at the end |
| 14:48 | <annevk> | oh, glossary is a nice touch |
| 14:48 | <annevk> | maybe we should add that to Anolis |
| 14:48 | annevk | summons Ms2ger |
| 14:48 | <annevk> | I mostly use "Terminology" now for terms defined by other specs |
| 14:48 | <annevk> | but ideally we get workable cross-spec cross-references for that |
| 14:49 | <annevk> | XSXR, sounds like some kind of vulnerability |
| 14:50 | <karlcow> | I remember this effort for a while http://www.w3.org/2003/glossary/ but has not been updated. People using too many ways of describing the vocab |
| 14:52 | <annevk> | maybe after a couple more rewrites of all core specs we'll have an idea of what we are doing and can write down a nice simple glossary :) |
| 14:52 | <karlcow> | heh |
| 14:52 | <karlcow> | living hope |
| 14:52 | <karlcow> | ambiguity is at the root of what we do. :) |
| 14:52 | hsivonen | wonders what's happening with WebGL in the Opera land |
| 14:53 | <karlcow> | http://www.google.com/search?client=opera&rls=fr&q=site:opera.com+webgl&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest |
| 14:55 | <hsivonen> | karlcow: http://www.google.com/search?q=site:www.opera.com+webgl seems more relevant |
| 14:56 | <karlcow> | hmmm not sure. Most of the blogs are on my.opera.com :) |
| 14:56 | <karlcow> | on www.opera.com, you will find things which are already deployed |
| 14:57 | <karlcow> | http://www.opera.com/docs/specs/presto27/ |
| 14:57 | <karlcow> | webgl is not deployed for sure. |
| 15:24 | <karlcow> | discovering http://sideshowbarker.github.com/console-spec/ |
| 15:40 | <MikeSmith> | karlcow: not much there to discover yet :) |
| 15:41 | <karlcow> | but cool to see it started. |
| 15:41 | <MikeSmith> | v0.1 |
| 15:42 | <MikeSmith> | hoping I can get somebody else do finish the 99.9% of work remaining to actually spec it out |
| 15:42 | karlcow | is checking https://bitbucket.org/scope/dragonfly-stp-1/src/b1e2a7ba97c0/src/console-logger/ |
| 15:44 | MikeSmith | didn't look at that yet |
| 15:44 | <karlcow> | https://bitbucket.org/scope/dragonfly-stp-1/history/src/console-logger/console.js |
| 15:44 | <MikeSmith> | console behavior is deceptively simple |
| 15:44 | <MikeSmith> | it is not quite as simple to try to spec |
| 15:45 | <MikeSmith> | for one thing, console object is now implemented in places other than browser GUI |
| 15:45 | <MikeSmith> | oh man |
| 15:45 | <MikeSmith> | I realize I need to publish a new version of this thing |
| 15:46 | <MikeSmith> | the source has a bunch of changes |
| 15:46 | <karlcow> | :) |
| 15:49 | <MikeSmith> | hmm, wtf… I remember making some changes but they don't seem to show up in the published version |
| 15:50 | <zcorpan> | console supports printf-like format strings? really? |
| 15:52 | <MikeSmith> | zcorpan: well, tell me what else to call that |
| 15:53 | <MikeSmith> | "printf-like" is intentionally vague |
| 15:53 | <zcorpan> | i don't mind the terminology, i was just surprised that it was supported |
| 15:53 | <MikeSmith> | oh |
| 15:53 | <MikeSmith> | yeah, it does |
| 15:53 | <MikeSmith> | that's another spec wrinkle actually |
| 15:53 | <MikeSmith> | or interoperability wrinkle |
| 15:54 | <MikeSmith> | because some implementations only support that if the format string is the first argument |
| 15:54 | <MikeSmith> | others do even if it's not the first |
| 15:55 | <zcorpan> | does opera support it? |
| 15:55 | <MikeSmith> | yeah |
| 15:55 | <MikeSmith> | dude |
| 15:55 | <MikeSmith> | do you please use Dragonfly |
| 15:55 | <MikeSmith> | dogfood |
| 15:56 | <zcorpan> | i use dragonfly :) |
| 15:57 | <MikeSmith> | whew |
| 15:57 | <MikeSmith> | you had me worried for a second |
| 15:57 | <MikeSmith> | OK, pushed new version |
| 15:57 | <zcorpan> | i get "%s, foo" for console.log("%s", "foo") in df |
| 15:57 | <hasather> | MikeSmith: we don't support printf |
| 15:57 | <MikeSmith> | oh |
| 15:57 | <MikeSmith> | well, I'm the dumbass ethen |
| 15:57 | <MikeSmith> | I could have sworned that you did |
| 15:57 | gsnedders | doesn't use Dragonfly, mainly because everything he does is debugging JIT bugs, and having esdebug Scope service attached disables JIT |
| 15:58 | <hasather> | MikeSmith: it's coming though |
| 15:58 | <MikeSmith> | k |
| 15:58 | <jgraham> | karlcow: the console scope service doesn't have that much to do with what MikeSmith is working on |
| 15:58 | <zcorpan> | good thing somebody is writing a spec for it then :) |
| 15:58 | <MikeSmith> | heh |
| 15:58 | <MikeSmith> | yeah, hopefully somebody other than me |
| 15:58 | <MikeSmith> | I made the proof of concept |
| 15:59 | <MikeSmith> | somebody smarter than me can make the actual spec |
| 15:59 | karlcow | hides |
| 15:59 | <zcorpan> | MikeSmith: i'm afraid you might have made a huge mistake there and will be stuck with it |
| 15:59 | <jgraham> | MikeSmith: BTW, did you see http://www.w3.org/html/wg/wiki/Testing/Infrastructure/Requirements/ ? |
| 15:59 | jgraham | will post to the list soon |
| 16:00 | <MikeSmith> | jgraham: didn't see it |
| 16:00 | <MikeSmith> | but thanks |
| 16:00 | <MikeSmith> | very much |
| 16:00 | <MikeSmith> | btw, I looked at a couple of existing annotation services |
| 16:00 | <karlcow> | I remember something along what zcorpan is saying about bugs. When bugs are assigned to someone, people do not take them. It is better to leave them unassigned until someone really does the work |
| 16:00 | <MikeSmith> | Shift+Space for one |
| 16:00 | <MikeSmith> | http://www.shiftspace.org/ |
| 16:01 | <MikeSmith> | and other which name I forget |
| 16:02 | <MikeSmith> | http://reframeit.com/ |
| 16:02 | <MikeSmith> | both are add-ons for FF |
| 16:03 | <MikeSmith> | though Reframeit has a bookmarklet alternative |
| 16:03 | <MikeSmith> | which didn't seem to work for me completely |
| 16:04 | <MikeSmith> | did I mention that I just pushed an update of the console spec? |
| 16:04 | <MikeSmith> | http://sideshowbarker.github.com/console-spec/ |
| 16:04 | karlcow | is reading the mess about "Expect: 100-continue" |
| 16:07 | <MikeSmith> | no idea what that is |
| 16:07 | <MikeSmith> | probably some list mail I should be reading but haven't yet |
| 16:08 | <zcorpan> | MikeSmith: you have severely typoed "Living Standard" |
| 16:08 | <MikeSmith> | /me notice http://httpstat.us/ getting some love |
| 16:08 | <jgraham> | hsivonen: yt? I was wondering if there would be some way to add support for document.write to the html5lib test format, for cases where using the test as input to document.write should produce different output |
| 16:08 | <jgraham> | Well obviously there is *some* way, but I mean a way that would work well for you |
| 16:09 | <MikeSmith> | zcorpan: where!? I am the strongest believer in the "Living Standard" dogma… even more than Hixie and annevk |
| 16:09 | <jgraham> | (different compared to the normal parser case) |
| 16:09 | <MikeSmith> | they just think they believe in it more |
| 16:10 | <jgraham> | Oooh, a license to sell copies of the document |
| 16:10 | <jgraham> | I wonder what the market rate for a Console spec is |
| 16:10 | <MikeSmith> | anyway, the other problem with console is that it's been implemented outside of browsers |
| 16:10 | <MikeSmith> | e.g., in s Node and PhantomJS. |
| 16:11 | <jgraham> | Is that a problem? |
| 16:11 | <zcorpan> | MikeSmith: "Unofficial Draft" |
| 16:11 | <jgraham> | I mean they don't have to be interoperable with browsers |
| 16:11 | <MikeSmith> | zcorpan: blame Berjon |
| 16:11 | <MikeSmith> | jgraham: other console documentation has stuff about "display a clickable hypertext view of the object" |
| 16:11 | <MikeSmith> | jgraham: I guess |
| 16:12 | <karlcow> | I'm slowing making my case against 100-continue when used over the public Web |
| 16:12 | <MikeSmith> | jgraham: but I thought our goal was to spec out abstract APIs when we can |
| 16:12 | <MikeSmith> | and not make assumptations |
| 16:12 | <MikeSmith> | or even assumptions |
| 16:13 | <jgraham> | MikeSmith: Right, that makes sense |
| 16:13 | <jgraham> | So don't specifiy that it must make a clickable hypertext view |
| 16:14 | <jgraham> | Just leave all of that as vendor extensions |
| 16:14 | <jgraham> | It doesn't need to be interoperable |
| 16:14 | <jgraham> | as long as it doesn't throw unexpectedly |
| 16:15 | <MikeSmith> | that is exactly what I am attempting to do |
| 16:15 | <jgraham> | Add some May level fluff about clickable hypertext views |
| 16:15 | <MikeSmith> | Webkit folk have told me they are going to yank a number of the methods that have already implemented |
| 16:15 | <MikeSmith> | trace thing for one |
| 16:15 | <MikeSmith> | actually, Sam told me that |
| 16:15 | <MikeSmith> | to name names |
| 16:16 | <MikeSmith> | and I trust Sam implicitly |
| 16:16 | <MikeSmith> | and I act on that sense of trust |
| 16:16 | <TabAtkins> | matjas: I wonder if Gmail is throttling me? I suspect I'm pinging the email server at least every few minutes, possibly more often. |
| 16:16 | <TabAtkins> | matjas: I need to spend time today writing a caching layer. |
| 16:16 | <matjas> | TabAtkins: Go ask the Gmail team :) |
| 16:17 | <MikeSmith> | jgraham: this why I spec'd it with this "console handler" invention |
| 16:17 | <matjas> | TabAtkins: Woohoo, caching. Om nom nom |
| 16:17 | <MikeSmith> | or abstraction |
| 16:17 | <MikeSmith> | which may or may not map to implementation |
| 16:17 | <jgraham> | I see |
| 16:18 | <MikeSmith> | anyway, I would really, really prefer that somebody else get some enthusiasm about speccing this |
| 16:18 | MikeSmith | crosses fingers |
| 16:18 | <MikeSmith> | I want to be a spec writer just about as much as I want to be a working-group chair |
| 16:20 | <MikeSmith> | zcorpan: to be clear, the "Unofficial Draft" stuff is boilerplate generated by Respec |
| 16:21 | <Ms2ger> | MikeSmith, all of us would really like someone to take over our specs ;) |
| 16:21 | <MikeSmith> | if I could get one of my secretaries to do it, that would be great |
| 16:23 | <MikeSmith> | one professor I work with actually has something like like 7 secretaries |
| 16:23 | <MikeSmith> | I kid you not |
| 16:23 | <zcorpan> | one for each day of the week? |
| 16:23 | <TabAtkins> | Man, I don't want anyone to take over my specs. I like writing specs. |
| 16:24 | <Ms2ger> | TabAtkins, do you happen to be interested in ranges? |
| 16:24 | <TabAtkins> | God no. |
| 16:24 | <jgraham> | TabAtkins: That's your dictatorial streak |
| 16:24 | <Ms2ger> | innerHTML? |
| 16:24 | <TabAtkins> | Let me rephrase. I like writing CSS specs. |
| 16:24 | <MikeSmith> | zcorpan: dunno what they all do, but when I want to e-mail him, i have to e-mail this alias address that goes to all his secretaries |
| 16:24 | <Ms2ger> | innerText? |
| 16:24 | <TabAtkins> | That's all you. |
| 16:25 | <Ms2ger> | No, innerText most certainly isn't me |
| 16:25 | <TabAtkins> | Anyway, I'm all booked up for spec writing for the next year or so. |
| 16:25 | <Ms2ger> | I just want it to die |
| 16:25 | <TabAtkins> | Got a half-dozen on my plate, at least. |
| 16:25 | <zcorpan> | MikeSmith: you should say that Console is a CSS module and TabAtkins will take over it |
| 16:25 | <TabAtkins> | Phrase it in terms of the box model and I'm all over it. |
| 16:25 | <Ms2ger> | Only *half* a dozen? :) |
| 16:26 | <TabAtkins> | Actually... you might be right. It's closer to a dozen. |
| 16:27 | <TabAtkins> | Images, Flexbox, Positioning, Grid/Template, Generated Content, Lists, Variables, Mixins, Modules, Selector Nesting, Box Model Additions, maybe Box Model, SVG Image Baseline. |
| 16:27 | <TabAtkins> | I think that's my current list. |
| 16:27 | <TabAtkins> | So that's either 12 or 13. |
| 16:28 | <Ms2ger> | Box Model would be really awesome :) |
| 16:28 | <TabAtkins> | Yeah, I know. It'll just be so annoying to write. |
| 16:28 | <jgraham> | Maybe BoxModel = Nothing | Just BoxModel |
| 16:28 | <TabAtkins> | I wont' even think about it until late Q3, though. |
| 16:29 | <TabAtkins> | MONADS |
| 16:29 | <zcorpan> | TabAtkins: do you have one spec assigned for each month of the year? :) |
| 16:29 | <Ms2ger> | By then, Anne will probably have a good definition of a tree you can use ;) |
| 16:29 | <TabAtkins> | Um, more or less, yeah. |
| 16:53 | <TabAtkins> | Hixie: Note that 'image-rendering' has nothing to do with optimization. It *used* to, which is why I map both of the old values to 'auto'. It is instead purely about intent - some images shouldn't be scaled with a blurring algorithm. |
| 17:10 | <TabAtkins_> | Hixie: Could you just change the :active section to say "For the purposes of Selectors, 'activating' an element means..." |
| 17:10 | <TabAtkins_> | Hixie: That's the only actual disconnect between CSS and HTML right now, if you ignore the fact that CSS's definition is underspecified. |
| 17:15 | <annevk> | Ms2ger, the current one is no good? |
| 17:15 | <annevk> | Ms2ger, btw, I renamed and it changed the URL... https://bitbucket.org/ms2ger/dom-core |
| 17:15 | <Ms2ger> | Haven't reviewed it |
| 17:43 | <jgraham> | Bugzilla needs a throtte on words / bug / unit time |
| 18:00 | <jgraham> | Ms2ger, annevk: Is it known that getAttributeNS returns the empty string rather than null if the attribute is missing? |
| 18:00 | <jgraham> | At least in webkit / gecko |
| 18:00 | <Ms2ger> | Yes |
| 18:00 | <Ms2ger> | annevk removed the note I had about that :) |
| 18:02 | <zcorpan> | null seems more useful |
| 18:03 | <jgraham> | Right, I'm not complaining if it isn't a web-compat problem |
| 18:03 | <Ms2ger> | You would know if it was :) |
| 18:06 | <jgraham> | Well, maybe |
| 18:06 | <jgraham> | If I had perfect knowledge of all bugs |
| 18:06 | <Ms2ger> | You == Opera |
| 18:06 | <jgraham> | Well, maybe :p |
| 18:07 | <jgraham> | (anyway, I can't see any obvious evidence it is a problem and if Gecko _ WebKit are happy to change it is all good) |
| 18:07 | <jgraham> | s/_/+/ |
| 18:09 | <AryehGregor> | jgraham, I could have >60,000 tests instead of ~1500. It's a few lines' change. Then Gecko/WebKit pass like 90%+ of tests and Opera/IE9 pass more like 70%. But my original version is much handier if you want to actually see what problems you're having. |
| 18:09 | <jgraham> | AryehGregor: I plan to make the output better |
| 18:10 | <jgraham> | Like maybe show Number of passes / fails/ timeouts / etc. and have checkboxes to hide/show results in different categories |
| 18:10 | <jgraham> | suggestions welcome |
| 18:11 | <AryehGregor> | My framework is tailored to my tests, so it knows to do things like group together the same tests for different attributes if they fail the same way. So I don't think a general-purpose harness will wind up being as concise no matter what. |
| 18:11 | <AryehGregor> | Concise, useful, whatever. |
| 18:11 | <jgraham> | Sure, but it can clearly be better than it is now |
| 18:11 | <AryehGregor> | Anyway, however you slice it, IE and Opera will fail a huge number of tests due to null handling. |
| 18:12 | <AryehGregor> | Definitely. |
| 18:12 | <zcorpan> | "And I just had to perjure myself when signing-up by saying,"I am only going to post messages about HTML5"!!!" - http://forums.whatwg.org/viewtopic.php?t=4523 |
| 18:13 | <AryehGregor> | The philosophy I'm adopting is that I'll test whatever makes sense and not pay much attention to how much that skews failure percentages. Because it's inevitable that some individual bugs will cause massive failures. |
| 18:13 | <zcorpan> | Hixie: besides being wrong these days, it's also annoyingly long, and i'm not sure it's helpful against spam anyway |
| 18:13 | <zcorpan> | Hixie: could we disable the antispam plugin on the forums? |
| 18:13 | <jgraham> | AryehGregor: It's not a problem if we fail lots of tests due to null handling (except in the sense that we have a bug we need to fix), but it is a problem if we can't see other problems due to the null issues |
| 18:13 | <AryehGregor> | Yes, I'm thinking that's what the original version is good for. |
| 18:14 | <AryehGregor> | However you slice it, if you have a failed assert aborting the test, one failed assert will mask subsequent ones. |
| 18:14 | <jgraham> | Right, so try not to assert for unrelated things in the same test |
| 18:14 | <AryehGregor> | Define "unrelated". |
| 18:15 | <jgraham> | It's a judgement of course |
| 18:15 | <jgraham> | But it sounds like you are generally winding up with tests that can fail for many different reasons |
| 18:16 | <AryehGregor> | The only logical things I see are to make one test per tested attribute (dozens of asserts per test), or one assert per test. |
| 18:16 | <jgraham> | One assert per test sounds more reasonable in that case |
| 18:16 | <AryehGregor> | Well, I'm happy to go either way. |
| 18:16 | <AryehGregor> | Ms2ger said he preferred the other way, and I weakly prefer it too. |
| 18:17 | <AryehGregor> | Given the existence of the original version. |
| 18:17 | <jgraham> | Well doing it this way seems to have harmful effects and I'm not sure what the benefits are |
| 18:17 | <jgraham> | Indeed it is the strongest argument yet that making a test/assert distinction is harmful |
| 18:18 | <jgraham> | biab |
| 18:33 | <AryehGregor> | heycam, could you make a decision one way or another on what null should cast to for WebIDL? Apparently web-compat requires "null"; it would be nice if the spec said so. This is blocking some HTML tests I want to write. http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString |
| 18:34 | <Ms2ger> | s/"null"/""/ |
| 18:34 | <AryehGregor> | Um, yeah. |
| 18:34 | <AryehGregor> | That's what I meant. :) |
| 18:34 | <Ms2ger> | Not what you said :) |
| 18:35 | <AryehGregor> | Now can someone point out to me what WebIDL says to do when you do something like "delete document.body.id"? |
| 18:35 | <AryehGregor> | I'm pretty sure the correct answer is "do nothing", but I can't see where it says that. |
| 18:36 | <AryehGregor> | jgraham, the reason I like combining the tests a bit more is it encourages implementers to fix bugs more, since it magnifies the difference between a nearly bug-free implementation and a relatively buggy implementation. With one assert per test, nobody's going to get less than 70% regardless. |
| 18:36 | <AryehGregor> | But my preference is weak. |
| 18:37 | <AryehGregor> | If the testing TF has an opinion, I'll change it back. |
| 18:40 | <AryehGregor> | I suspect I don't know ES well enough here . . . |
| 18:40 | Ms2ger | checks |
| 18:40 | <Ms2ger> | return true, I think |
| 18:40 | <AryehGregor> | Where do you see that? |
| 18:41 | <Ms2ger> | WebIDL 4.4.5: there MUST be a corresponding property on the interface prototype object, unless: |
| 18:41 | <Philip`> | I'd imagine implementers would be more encouraged to fix bugs if the tests accurately pointed out all the bugs, rather than if they obscured the results in order to manipulate the percentages |
| 18:41 | <Ms2ger> | IIRC, that means [[GetOwnProperty]] returns undefined |
| 18:41 | <AryehGregor> | Philip`, well, my original version is much more convenient for that anyway. |
| 18:42 | <AryehGregor> | And I do link to it at the top of the test. |
| 18:42 | <AryehGregor> | Ms2ger, okay, I'm just going to assume you're right. |
| 18:42 | <Ms2ger> | That's not a good idea in this area, generally :) |
| 18:43 | <Ms2ger> | Philip`, are you planning to fix your test bugs soon, btw? |
| 18:46 | Ms2ger | wanted to file a WebIDL bug, noticed AryehGregor already did |
| 18:51 | <zewt> | AryehGregor: a good test suite should, whenever possible, expose a particular bug with a particular test; a single bug should only cause multiple tests to fail if the tests are inherently overlapping |
| 18:52 | <Philip`> | Ms2ger: Depends on what is considered "soon" |
| 18:52 | <AryehGregor> | zewt, that's what my original test harness does. |
| 18:52 | <Philip`> | I could probably find this weekend to catch up on the known problems |
| 18:52 | AryehGregor | shrugs |
| 18:52 | <Ms2ger> | That would be nice |
| 18:52 | <AryehGregor> | Makes no difference to me. Right now I'm working on adding more tests. |
| 18:53 | <Ms2ger> | Otherwise Kris will spend half of the next few telcons on them :) |
| 18:53 | <dean-> | zcorpan: Hi, I have some feedback on your html5 elements webpage. I wonder if it would be good if you also showed what elements are able to be used as children of each element. Anyway, I think the page is great and it gives people a good intro to the features of html, so thanks for creating the site. |
| 18:54 | <Philip`> | s/find this weekend/find time this weekend/ |
| 18:55 | <Philip`> | (It's not like the weekend itself is at all challenging to find) |
| 19:02 | <dean-> | zcorpan: http://krijnhoetmer.nl/irc-logs/whatwg/20110212#l-403 |
| 19:03 | <AryehGregor> | Why can't the spec splitter make xrefs work right in the multipage version? :( |
| 19:03 | <AryehGregor> | (specifically the backlinks) |
| 19:03 | <AryehGregor> | (I guess because those are generated by JS for some crazy reason?) |
| 19:04 | <AryehGregor> | I guess the logical place to test the rules for parsing non-negative integers is in reflection tests, right? |
| 19:04 | <AryehGregor> | So I suppose I should implement that in JavaScript. |
| 19:04 | AryehGregor | does so |
| 19:05 | <Philip`> | If the xrefs were handled earlier (e.g. by Anolis, I guess) then it'd probably work better in the multipage one |
| 19:05 | <Philip`> | (I don't think the splitter itself would be a good place to implement the xref feature) |
| 19:06 | <Ms2ger> | What needs to be handled? |
| 19:07 | <Philip`> | AryehGregor: gsnedders had some old tests for the microsyntaxes - maybe you could use something like that, and pass the values through the reflection system? |
| 19:08 | <AryehGregor> | Where are they? |
| 19:08 | <AryehGregor> | It would take me about ten minutes to write my own, so . . . |
| 19:08 | <Ms2ger> | Listed on the WHATWG wiki |
| 19:09 | <Philip`> | Ms2ger: Associating each element that has an id with every element that links to it, so a script can find all the backrefs without having to scan the whole document, I guess |
| 19:09 | <Ms2ger> | Mike wrote that, I think |
| 19:09 | <Workshiva> | What if every element had a uuid... |
| 19:10 | <TabAtkins> | httpstat.us is awesome. |
| 19:19 | <k0rnel> | wtf 418 :) |
| 19:19 | <TabAtkins> | April 1 RFCs rock. |
| 19:20 | <k0rnel> | yea, looking at it now |
| 19:23 | <heycam> | AryehGregor, I will get back to editing Web IDL in a couple of weeks, so yes. (Anne was recently asking about this recently, too.) |
| 19:23 | <AryehGregor> | heycam, great, thanks. |
| 20:01 | <AryehGregor> | "Let rounded-value be the number in S that is closest to value, selecting the number with an even significand if there are two equally close values." How is this actually supposed to be implemented? |
| 20:02 | <AryehGregor> | Oh, gsnedders cheated and just hardcoded the correct values. |
| 20:02 | AryehGregor | gives up on implementing the float parsing algorithm in JavaScript |
| 20:10 | <Philip`> | AryehGregor: By "cheated" you mean "wrote it in a way that is much more robust and easily verified than a custom-written parser"? |
| 20:11 | <AryehGregor> | It's strictly harder to verify manually-written expectations than auto-generated ones, since in the auto-generated case you can always enumerate all the expectations. |
| 20:22 | <Hixie> | TabAtkins: 'image-rendering' looked a lot like an optimisation feature when i looked, but i'm glad i'm wrong |
| 20:22 | <TabAtkins> | Yeah, it just means "use a smooth scaling algorithm" or "use a pixel-art scaling algorithm". |
| 20:23 | <TabAtkins> | The old 'optimizeSpeed' and 'optimizeQuality' values are aliases for 'auto' (smooth blend) now. |
| 20:23 | <Ms2ger> | Why? |
| 20:23 | <TabAtkins> | Why to which? |
| 20:23 | <Ms2ger> | optimize* > auto |
| 20:24 | <TabAtkins> | Because user agents should always be optimizing both speed and quality as much as possible given the system constraints. |
| 20:24 | <TabAtkins> | Also: because the definition of a "speedy" and "quality" scaling algorithm changes as computing resources become cheaper. |
| 20:25 | <zewt> | well, there are three meaningful choices, not two |
| 20:25 | <zewt> | "be as fast as possible", "be as high quality as possible", and "use the most general-purpose tradeoff" |
| 20:26 | <TabAtkins> | In practice, you always want the third. |
| 20:26 | <zewt> | no, not really |
| 20:26 | <TabAtkins> | The UA *must* use a cheaper algo when it's fighting for CPU, even if you say to use high-quality. |
| 20:26 | <zewt> | if you're an image host and you're displaying an image scaled to the user's browser window, you want to hint the browser to choose quality over speed |
| 20:26 | <TabAtkins> | Similarly, the UA *should* use better algos when doing so is easy, even if you at some point in the past mistakenly thought that it should be using only cheap ones. |
| 20:27 | <TabAtkins> | The browser should always choose as much quality as possible, given the resources it has. |
| 20:28 | <zewt> | that assumes it's possible to make a correct heuristic determination when the image is rendered; I'm not sure that's reasonable |
| 20:28 | <AryehGregor> | TabAtkins, the browser can trade off rendering time against quality. |
| 20:28 | <AryehGregor> | The author might prefer that the image take longer to display but be higher-quality. |
| 20:28 | <AryehGregor> | The browser always has unlimited time, in principle. |
| 20:28 | <zewt> | and of course, the browser should always be allowed to ignore a hint like "use the best quality available"; it's always just a hint |
| 20:29 | <TabAtkins> | zewt: If it's possible *at all*, it's best done by the browser at the moment the iamge is rendered, rather than an author at some point in the past who has no idea what sort of device the user is running on. |
| 20:29 | <AryehGregor> | If you're providing the image for download, you might be okay with it taking significantly longer to scale. |
| 20:29 | <zewt> | (well, not necessarily with things like canvas blitting, but for page rendering) |
| 20:29 | <AryehGregor> | The browser doesn't know what purpose the author intends the image be used for. |
| 20:29 | <TabAtkins> | AryehGregor: Scaling has no effect on downloading. |
| 20:29 | <AryehGregor> | Yes, true, not in this case. |
| 20:29 | <AryehGregor> | For, say, canvas, that wouldn't be true. |
| 20:30 | <AryehGregor> | I can't think of any case where you'd have good reason to change it around for CSS. |
| 20:30 | <TabAtkins> | An author who, in 2005, thought that his image was too big and should thus use a cheap scaling algorithm, is wrong now in 2011. |
| 20:30 | <TabAtkins> | Similarly, the author who thought that his image scaled fine with a high-quality algo on his desktop machine is wrong when I view the site on my phone. |
| 20:30 | <zewt> | how is a browser going to know that the purpose of a page is displaying an image, so the quality of scaling a particular image is more important than usual, and more important than other images on the page? |
| 20:31 | <TabAtkins> | zewt: If you're scaling every image on the page, you're doing things wrong. |
| 20:31 | <zewt> | if higher-quality image scaling becomes very cheap, then at that point browsers are free to simply ignore the hint |
| 20:31 | <zewt> | TabAtkins: no, that's an incorrect generalization |
| 20:31 | <TabAtkins> | zewt: It's already true. It used to be that bilinear scaling was the "quality" algorithm. Now, bilinear is easy and cheap on the GPU, so you can almost always use it, and algos like Lanczos are the "high-quality" version. |
| 20:32 | <zewt> | so browsers should be free to treat "high quality" hints as lanczos (which is what I'd expect, with today's hardware) |
| 20:32 | <zewt> | (desktop hardware, that is) |
| 20:33 | <TabAtkins> | Browsers should be free to *always* use Lanczos, if they can grab the CPU for it. |
| 20:33 | <zewt> | if lanczos scaling becomes the "cheap" algorithm, browsers can treat that as the default, or at that point simply stop paying attention to "high-quality" hints entirely |
| 20:33 | <zewt> | TabAtkins: sure; I'm not suggesting anything but a hint |
| 20:33 | <TabAtkins> | And they should be free to drop down to nearest-neighbor if there's too much going on, regardless of what the author indicates. |
| 20:33 | <TabAtkins> | zewt: I understand. My point is that hinting in this way provides very close to zero benefit for the browser. |
| 20:34 | <zewt> | and I think that's wrong. |
| 20:34 | <TabAtkins> | Okay. |
| 20:34 | <AryehGregor> | zewt, give specific real-world use-cases. |
| 20:34 | <TabAtkins> | I know that our graphics people agree that optimization-hinting isn't useful for this sort of thing. |
| 20:34 | <zewt> | i did; an image host that displays images scaled to the user's browser window |
| 20:34 | <TabAtkins> | (It can be useful in some cases.) |
| 20:35 | <zewt> | in that case, image quality is at the forefront, since the entire purpose of the page is displaying that image |
| 20:35 | <TabAtkins> | Heh, if image quality is at the forefront, you serve a larger image and don't scale at all. |
| 20:35 | <zewt> | but like I said: scaled to the user's browser window |
| 20:35 | <zewt> | you can't have a separate version of the image for every possible window size :) |
| 20:36 | <TabAtkins> | Sure. Now, how does a hint help the browser here? If it has the CPU for it, it'll use a high-quality scaling algo anyway. If it doesn't, it wont'. The only time the hint could possibly matter is if you're in a situation where lots of images need scaling and you have a lightly constrained CPU. |
| 20:37 | <AryehGregor> | zewt, is that actually a real-world use-case? Do you know of a site with that requirement? |
| 20:37 | <zewt> | but that's exactly what's wrong: it *won't* use a higher-quality algorithm |
| 20:37 | <TabAtkins> | And that depends on the browser detecting this and not just deciding that the best thing to do is bail and scale everything cheaply, so they dont' stress the CPU more than necessary. |
| 20:37 | <zewt> | firefox won't use lanczos to scale the image today |
| 20:41 | <zewt> | AryehGregor: http://oreno.imouto.org/post/browse#/order:random%20s (note: NWS content on that site, but that URL should filter it out) |
| 20:42 | AryehGregor | isn't interested in looking at sites like that |
| 20:42 | <TabAtkins> | That's still a valid case. ^_^ |
| 20:43 | <AryehGregor> | Hmm, nobody who implements reflected doubles follows the spec for IDL sets: data:text/html,<!doctype html><script>var el = document.createElement("meter"); el.max = 10000000000; alert([el.getAttribute("max"),Number("10000000000")]);</script> |
| 20:43 | <TabAtkins> | A site like that should be using unscaled thumbnails at the bottom, and then scale the main image. As it's the only image on the page being scaled, your case doesn't apply. |
| 20:43 | <AryehGregor> | getAttribute() returns "1e10", not "10000000000". |
| 20:44 | <zewt> | TabAtkins: the main image is scaled at runtime; double-click the window, or resize the browser |
| 20:44 | <TabAtkins> | zewt: Yeah, I understand. |
| 20:44 | <zewt> | (the thumbnails actually can be scaled, too, for mobile) |
| 20:44 | <TabAtkins> | But your use-case for hinting relies on there being many scaled images on the page, some of which can be low-quality and some which should be high-quality. |
| 20:45 | <AryehGregor> | Are 0 and -0 meaningfully different in JavaScript? |
| 20:46 | <Philip`> | Yes |
| 20:46 | <TabAtkins> | They're different IEEE doubles. |
| 20:46 | <Philip`> | Divide a non-zero value by them |
| 20:46 | <AryehGregor> | But 0 === -0, right? |
| 20:46 | <TabAtkins> | In webkit, yeah. |
| 20:46 | <Philip`> | Yes (but 1/0 !== 1/-0 so they're not actually equivalent) |
| 20:47 | <AryehGregor> | TabAtkins, Gecko and Opera too. |
| 20:47 | <AryehGregor> | Also String(-0) == "0". |
| 20:47 | <AryehGregor> | Confusing. |
| 20:47 | <TabAtkins> | So they're the same except where they're not. |
| 20:50 | <espadrine> | Well, 1/+0 is +infinity, right? And 1/-0 is -infinity... So it's not completely absurd. |
| 20:52 | <AryehGregor> | No, but I'd expect at least String(-0) == "-0". Although then 0 === -0 but String(0) != String(-0) . . . |
| 20:53 | <AryehGregor> | Maybe people shouldn't make up values that don't mathematically exist. :) |
| 20:53 | <zewt> | heh, floating-point infinity has got to be one of the biggest cases of where developers spend a lot of time thinking about something and very little time actually using it |
| 20:53 | <TabAtkins> | Maybe you should be more accepting of alternate mathematical models. |
| 20:53 | <AryehGregor> | There's a reason -0 is the same as 0 in mathematics. |
| 20:53 | <zewt> | in my 15-or-so years of using C, I've never once ever seen or written code that intentionally uses INF |
| 20:53 | <AryehGregor> | It's a one-line proof using the group axioms. |
| 20:54 | <TabAtkins> | Who needs groups? |
| 20:54 | <TabAtkins> | I do all my math over magmas. |
| 20:54 | <AryehGregor> | On the other hand, better than PHP's false == "0" != "" == false. |
| 20:55 | <AryehGregor> | Additive identities are useful. |
| 20:55 | <AryehGregor> | Well, JS sort of has one because it fakes equality. |
| 20:55 | <AryehGregor> | The operation isn't well-defined with respect to equality. |
| 20:55 | <AryehGregor> | This discussion is an example of the confusion that causes. |
| 20:59 | <zewt> | > But ideally, we should hash this out with Microsoft people weighing in here on es-discuss (I'm told they're not allowed to participate on whatwg lists). |
| 20:59 | <zewt> | heh |
| 21:07 | AryehGregor | succeeded in getting Opera to fail all tests in the -onepage version |
| 21:08 | <zewt> | i'm not entirely following what you're doing, but i have to seriously question the methodology if you're editing tests to make them fail in particular browsers, heh |
| 21:08 | <AryehGregor> | If someone can confirm for me how delete is supposed to work, then I can get WebKit to fail everything too because of: data:text/html,<!doctype html><script>delete document.head.id; alert(typeof document.head.id);</script> |
| 21:08 | <AryehGregor> | I wasn't really being serious. :P |
| 21:09 | <AryehGregor> | The onepage version is silly, it fails the whole test if there's a single detected bug in that particular attribute's reflection. |
| 21:09 | <AryehGregor> | I'll probably replace it with one that runs all the tests regardless. |
| 21:09 | <AryehGregor> | But I do think it's nice that I was able to find so many bugs in every browser. |
| 21:10 | <AryehGregor> | Sadly, I don't have time to continue isolating and reporting all of them like I was doing before. |
| 21:10 | <zewt> | want to know a fun bug? set a timer during pagehide in FF3.6 |
| 21:10 | <zewt> | iirc it'll be fired after the tab is closed, heh |
| 21:10 | <zewt> | fortunately, fixed in 4 |
| 21:11 | <AryehGregor> | Submit a test to the test suite! |
| 21:11 | <zewt> | heh, sort of an interesting challenge to come up with a way to test that |
| 21:11 | <zewt> | maybe trigger a page change with window.location, and have the timer set a flag in localStorage |
| 21:12 | AryehGregor | observes that Firefox, Chrome, and Opera take from 7 to 14 seconds to run his test suite, while IE9rc takes 74 seconds |
| 21:13 | <Ms2ger> | annevk, what do you need for the glossary thing? |
| 21:14 | <AryehGregor> | Okay, now back to execCommand(). |
| 21:14 | <AryehGregor> | If you, e.g., bold something like <div><p>Foo <p>Bar</div>, Gecko does <div style=font-weight:bold><p>Foo <p>Bar</div>. Everyone else does something like <div><p><b>Foo </b><p><b>Bar</b></div>. |
| 21:15 | <AryehGregor> | I initially specced the latter, but the former is starting to make more sense to me. |
| 21:15 | <AryehGregor> | Opinions? |
| 21:15 | <AryehGregor> | Specifically, you don't have to know anything about where <b> can validly go. |
| 21:15 | Ms2ger | tends to prefer matching Gecko :) |
| 21:15 | <AryehGregor> | In the latter approach, you have to know that you can't put it around the <div> or <p>, which is annoying. |
| 21:16 | <AryehGregor> | And will change if new elements are introduced. |
| 21:16 | <AryehGregor> | So I'm going to re-spec it. |
| 21:16 | <AryehGregor> | Ms2ger, everyone's going to have to rewrite their implementations from scratch anyway to match any conceivable spec, from what I've seen so far. |
| 21:16 | <AryehGregor> | Since everyone does crazy different things. |
| 21:16 | <Ms2ger> | Aww |
| 21:17 | <AryehGregor> | Unless I just spec exactly what one browser does. |
| 21:17 | <AryehGregor> | Or almost exactly. |
| 21:17 | <AryehGregor> | Maybe if Gecko's sufficiently saner than everyone else, I'll do that. We'll see. |
| 21:19 | <erlehmann> | implying gecko was sane |
| 21:19 | <zewt> | the implication knocked him offline |
| 21:22 | <zewt> | AryehGregor: what are you referring to, re "bold something"? |
| 21:22 | <AryehGregor> | zewt, execCommand(). |
| 21:23 | <zewt> | (makes me wonder what happens if you then unbold "Foo"--inserting another font-weight: makes sense) |
| 21:24 | <AryehGregor> | Depends where your selection is. |
| 21:24 | <zewt> | eg. you can bold things with <b>, but there's no element-level analogue for un-bolding as there is with font-weight |
| 21:24 | <AryehGregor> | Unbolding "<b>Foo</b>" results in "Foo". |
| 21:25 | <AryehGregor> | Unbolding the "oo" in "<b>Foo</b>" results in "<b>F</b>oo". Etc. |
| 21:25 | <AryehGregor> | In fact, bolding "Foo <strong>bar</strong>" generally results in something like "<b>Foo bar</b>". |
| 21:25 | <zewt> | yeah--seems like that would get a little complicated with nesting, eg. <b><i>Foo</i></b>--now unbold "oo" and you have to shuffle stuff around |
| 21:25 | <AryehGregor> | It's all evil magic, and I aim to uncover its deepest secrets and expose them to the light of day. |
| 21:26 | <AryehGregor> | Yep, undoubtedly. |
| 21:26 | <AryehGregor> | I'll find out! |
| 21:32 | <AryehGregor> | Wait, am I smoking something? |
| 21:32 | <AryehGregor> | Now Gecko's behaving differently. |
| 21:32 | <AryehGregor> | :( |
| 21:32 | <zewt> | heisenbrowser |
| 21:33 | <AryehGregor> | Oh, there's a styleWithCSS command . . . sigh. |
| 21:34 | <zewt> | dreaming of a world where i can tell gmail to ignore fonts in emails |
| 21:36 | <AryehGregor> | No, I'm just confusing myself even more. Sigh. |
| 23:04 | <annevk> | Ms2ger, just thinking it could be done automatically be extracting <dfn> |
| 23:04 | <annevk> | Ms2ger, not entirely sure that is gonna work nicely, but it might be interesting |
| 23:07 | <othermaciej> | annevk: fonts wg telecon went reasonably well today |
| 23:08 | <othermaciej> | (though I wish Håkon had showed up) |
| 23:10 | <annevk> | he was at the Opera |
| 23:10 | <othermaciej> | so I heard |
| 23:10 | <annevk> | he tried calling me but I was away too |
| 23:11 | <othermaciej> | fortunately I'm willing to be the one guy on the call who disagrees with everyone else :-) |
| 23:11 | <othermaciej> | it seemed though that there was agreement that: |
| 23:11 | <othermaciej> | (a) font embedding restrictions should be defined by @font-face, not by WOFF |
| 23:11 | <othermaciej> | (b) the way to change from the default restrictions should be From-Origin (or whatever the name is) not CORS |
| 23:12 | <othermaciej> | only remaining point of disagreement was whether @font-face should default to From-Origin: same |
| 23:12 | <othermaciej> | but I think everyone at least understood the issues |
| 23:12 | <annevk> | that's some nice progress |
| 23:13 | <annevk> | sweet |
| 23:14 | <annevk> | whoa, Ms2ger pushes to W3C too now |
| 23:15 | <annevk> | I guess all I have to do now is write |
| 23:15 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#trees |
| 23:16 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#nodes-model are the major changes |
| 23:17 | <annevk> | and event dispatching is now based on this too to allow for Indexed DB |
| 23:19 | <othermaciej> | so it allows trees other than DOM Node trees? |
| 23:19 | <annevk> | apparently that is what Indexed DB wants |
| 23:20 | <othermaciej> | neat |
| 23:21 | <othermaciej> | maybe it also makes it easier to spec how Window takes part in event dispatch |
| 23:21 | <annevk> | yeah, though I don't want that in this spec |
| 23:21 | <annevk> | that should be in HTML or a browsing context spec (if we ever get one of those) |
| 23:37 | <jennb> | Hixie: ping |
| 23:43 | <zewt> | annevk: step 3 of event invocation sounds like event.target gets set to the first node the event is invoked on (eg. the root node during capture phase) and then left there |
| 23:44 | <zewt> | ah, it's also set by step 4 of dispatch ... so that's if invocation happens when not during dispatch? |
| 23:46 | <AryehGregor> | Does anyone know how long typical TLS handshake caching lasts in practice? |
| 23:46 | <Hixie> | jennb: here now |
| 23:46 | <AryehGregor> | Like an hour, a day, indefinitely? |
| 23:46 | <jennb> | Hixie: can you take a quick look at https://bugs.webkit.org/show_bug.cgi?id=54582 and see if the small change proposed is acceptable? |
| 23:47 | <Hixie> | looking |
| 23:48 | <Hixie> | jennb: is https://bug-54582-attachments.webkit.org/attachment.cgi?id=82686 a valid test case for this? |
| 23:48 | <jennb> | Hixie: yes |
| 23:48 | <Hixie> | i guess it depends on the browser default not being UTF-8 |
| 23:49 | <jennb> | Hixie: true... |
| 23:49 | <Hixie> | hold on, let me use my harness for these tests to check it in other browsers |
| 23:49 | <jennb> | Hixie: I checked manually on Firefox, Chrome and Safari. |
| 23:50 | <zewt> | it repros for me in Chrome: renders correctly with the meta tag, mojibake without it |
| 23:51 | <zewt> | (odd, I'd expect browsers to default to UTF-8 for local files by now, but in any case) |
| 23:52 | <Hixie> | jennb: there's something more going on than is described in that bug, given the behaviour i'm seeing in other browsers on http://www.hixie.ch/tests/adhoc/html/parsing/encoding/142.html |
| 23:53 | <Hixie> | IE8, FF trunk, Opera trunk, Safari WebKit trunk, and Chrome dev trunk all do the same thing on that test |
| 23:53 | <Hixie> | and that is not what the bug claims they do, unless i'm misunderstanding the bug |
| 23:55 | <jennb> | Hixie: 142.html doesn't test mispelled 'content' |
| 23:55 | <zewt> | "Generally speaking, making parsing more strict is rarely helpful." there's a controversial claim if ever there was one. heh |
| 23:55 | <annevk> | zewt, I think you spotted something that can be removed now |
| 23:56 | <zewt> | annevk: as long as the only reference to "invoke" is the one in "dispatch", then I think so |
| 23:57 | <Hixie> | jennb: it spells it "cotent" |
| 23:57 | <zewt> | is there a way to tell whether a particular part of a spec is meant to be referenced externally? for example, "dispatch an event" defines something other specs make use of, but "invoke an event" is just an internal "helper function" that probably shouldn't be referred to directly externally |
| 23:58 | <zewt> | _invoke_an_event? heh |
| 23:58 | <jennb> | Hixie: hmmm... i see that now. yet it passes... |
| 23:58 | <jennb> | Hixie: oh, it's supposed to fail, according to that bug. |
| 23:58 | <Hixie> | all the browsers do the same thing |
| 23:58 | <annevk> | zewt, it's leftover from https://bitbucket.org/ms2ger/dom-core/changeset/6c7a0c465d83 |
| 23:58 | <jennb> | Hixie: i'm confused now |
| 23:59 | <Hixie> | which is consistent with what the spec says (the test's "pass" condition is what the spec says) |
| 23:59 | <annevk> | zewt, there's no conventions |
| 23:59 | <Hixie> | jennb: (reload the test, you may be looking at an old version where i had the pass condition backwards) |
| 23:59 | <annevk> | zewt, maybe besides concept- we should have internal- or some such |
| 23:59 | <annevk> | zewt, so it's clear from the title= |