| 00:00 | <atw> | MessagePorts are supposed to implement EventTarget - does that mean that if I register an onmessage listener on a port, that my onmessage listener can get a reference to the port via the event.target attribute? Or is that only for DOM events? |
| 00:00 | <Hixie> | yes, it does mean that |
| 00:00 | <annevk3> | well yeah, I'm biased both ways, but chaals appreciates honesty |
| 00:00 | <Hixie> | annevk3: feel free to support me on the list then :-P |
| 00:01 | <annevk3> | Hixie, since when are we doing +1 emails? :p |
| 00:01 | <Hixie> | :-P |
| 00:01 | <atw> | That implies that we can't GC message ports if there are any messages in-flight even if there are no references to either endpoint's message port, since the messages themselves contain an inherent reference to the port. I could ping-pong messages back and forth between two ports using only listeners, with no active references to the ports. |
| 00:02 | <Hixie> | atw: correct, the spec even explicitly says that iirc |
| 00:03 | <atw> | Not so - the spec says: "Thus, a message port can be received, given an event listener, and then forgotten, and so long as that event listener could receive a message, the channel will be maintained. |
| 00:03 | <atw> | Of course, if this was to occur on both sides of the channel, then both ports would be garbage collected, since they would not be reachable from live code, despite having a strong reference to each other." |
| 00:03 | <atw> | Ah, but. |
| 00:03 | <atw> | The next line :) |
| 00:04 | <atw> | It does say that you can't GC a port while there's a message in flight, and the previous paragraph implies that this would keep the entangled port from being GC'd. OK, thnx. |
| 00:04 | <atw> | I for some reason couldn't hold those two facts in my brain at once. |
| 00:04 | <Hixie> | i can make it clearer if you want |
| 00:04 | <Hixie> | drop me a mail? |
| 00:04 | <Hixie> | i'm in the middle of the svg edits right now |
| 00:04 | <Hixie> | so can't make changes |
| 00:04 | <atw> | Sure, but in retrospect I think it's plenty clear. Thx. |
| 00:22 | <annevk3> | Hixie, SVG is going to be commented "in"? |
| 00:22 | <annevk3> | (I guess the quotemarks should have been around commented....) |
| 00:23 | annevk3 | clearly needs to go to sleep; night all! |
| 00:43 | <Lachy> | Hixie, personally, I think supporting <![CDATA[]]> sections in SVG scripts, but not in HTML scripts is silly. I would prefer that we just made <script> parse as CDATA for both HTML and SVG, as that makes it easier for authors |
| 00:43 | <Lachy> | well, at least, it makes it more consistent |
| 00:43 | <Hixie> | we can't do that while satisfying the svgwg's goal |
| 00:43 | <Lachy> | I don't agree with the SVG WG's goal |
| 00:44 | <Hixie> | neither do i, but we can't just throw out people's requirements willy nilly just because we don't like them |
| 00:44 | <Lachy> | I think making SVG as XML entirely compatible with text/html, including XML's syntactic sugar, is a non-goal |
| 00:44 | <Lachy> | er, I don't think I said that quite right. But you should get what I mean |
| 00:45 | <Hixie> | their goal is to be able to take svg documents created by xml serialisers and paste them into text/html docs |
| 00:45 | <Lachy> | yeah. I don't agree with that |
| 00:45 | <Hixie> | you think we should prevent it, or you think it's not important? |
| 00:45 | <Hixie> | i.e. do you think it's an anti-goal, or a non-goal? |
| 00:45 | <Lachy> | I think text/html SVG and XML SVG should be just as compatible as HTML and XHTML |
| 00:46 | <Hixie> | that's a fine goal too, but it conflicts with their goal |
| 00:46 | <Lachy> | I know. i don't care about their goal |
| 00:47 | <Hixie> | they do |
| 00:47 | <Lachy> | I care about making the authoring requirements consistent for authors |
| 00:48 | <Hixie> | they care about being able to paste svg images into text/html |
| 00:49 | <Hixie> | wtf, windows is actually forcing me to reboot with a 30 minute countdown |
| 00:50 | <Lachy> | sure. But I don't think it's necessary to be able to do that with SVG designed for XML processing to be copy and pasteable entirely without modification. I think requiring authors to strip (or comment out) unsupported XML syntactic sugar like CDATA sections |
| 00:50 | <Hixie> | and they disagree |
| 00:50 | <Lachy> | so the same way authors do <script>/*<![CDATA[ */ ... /* ]]> */</script> for XHTML as text/html, so should they for SVG as text/html |
| 00:50 | <Hixie> | this is why opinion-based arguments don't work. there's no way to win them. |
| 00:51 | <Lachy> | mine isn't opinion based. It's based on making rules consistent for authors |
| 00:51 | <Lachy> | so hand coding is easier |
| 00:53 | <shepazu> | what about sicking's suggestion for script/css CDATA parsing? |
| 00:53 | <Hixie> | and theirs isn't opinion based, it's based on making authoring easier for authors |
| 00:53 | <Hixie> | so hand coding is easier |
| 00:53 | <Hixie> | (they're both opinions) |
| 00:53 | <Hixie> | shepazu: that breaks your goal |
| 00:54 | <shepazu> | hmmm... how so? |
| 00:54 | <heycam> | the opinion part of it is which is more important: hand authoring, or paste authoring from existing SVG authoring tools |
| 00:54 | <shepazu> | sorry if I'm being dense, but it seemed to solve the issue... |
| 00:55 | <Hixie> | shepazu: making text/html not use xml-like parsing means that you can't guarantee that an xml svg file will work in text/html, no? |
| 00:56 | <Lachy> | Hixie, the SVG WG's goals seem to be to try and maintain as much XML-like strictness as possible. I have not seen any suggestion from the SVG WG specifically designed to optimise hand coding |
| 00:57 | <Lachy> | anyway, I'm not looking forward to try and explain the rules for dealing with script elements to authors now that the rules differ for HTML and SVG fragments. |
| 00:57 | <shepazu> | I thought sicking suggested supporting <![CDATA[]]> sections in HTML scripts and SVG scripts? |
| 00:58 | <Hixie> | i don't see any sane way to support <![CDATA[ ]]> in regular HTML given the crazy "magic <!-- -->" processing |
| 00:58 | <shepazu> | <![CDATA[]]> is not strictly necessary with SVG scripts... just when Offending Characters might be present, right? |
| 00:58 | <Hixie> | <![CDATA[ ]]> is never necessary in XML |
| 00:59 | <Hixie> | it's just a syntactic alternative to escaping characters using numeric character references ("entities") |
| 00:59 | <heycam> | i think it was a mistake for CDATA sections to be exposed in the DOM |
| 00:59 | <shepazu> | right |
| 01:00 | <Lachy> | shepazu, the problem is when authors using XML don't use CDATA sections and encode <, >, and & as character refs |
| 01:00 | <Hixie> | heycam: me too, but that's actually academic here |
| 01:00 | <Lachy> | when they do use them, the solution to make the script compatible with both XML and text/html is to comment out the <![CDATA[ ]]> markup. with /* */ or // |
| 01:01 | <Hixie> | the best thing would be to have a browser with significant market share implement a consistent mechanism (whatever that might be), and prove that it doesn't break sites and is implementable |
| 01:02 | <Hixie> | changing html parsing rules is a very dangerous sport |
| 01:02 | <Hixie> | and not one i particularly enjoy |
| 01:02 | <shepazu> | I thought that sicking seemed to say that you *could* do CDATA in script and style? |
| 01:02 | <Hixie> | sicking: can you explain to me how you would do it? |
| 01:02 | <Hixie> | i didn't see anything that wasn't rather handwavy |
| 01:03 | <Hixie> | and the parsing of CDATA blocks in text/html (not <![CDATA[ ]]> blocks) is significantly non-trivial right now |
| 01:03 | <shepazu> | (Hixie, did you BCC me on that email? I got 3 copies) |
| 01:03 | <Hixie> | yeah, i bcc'ed anyone who wrote an e-mail on the thread |
| 01:03 | <shepazu> | ok, thanks, mystery solved |
| 01:06 | <Lachy> | ah, that explains why I got an extra copy, even though I wasn't quoted. Though I don't remember writing anything in that thread |
| 02:40 | <gsnedders> | http://code.google.com/p/html5lib/source/list — there's far too much me there |
| 04:12 | <gsnedders> | Weee… from 136s (r1274) to 50s (HEAD) to tokenize the spec |
| 07:14 | <hsivonen> | lots of scrollback :-( |
| 07:24 | <shepazu> | here's the summary, hsivonen: SVG script is easier and more consistent than HTML script, so we will probably go with HTML's model, and Hixie rejected all the SVG WG's feedback for SVG-in-HTML |
| 07:25 | <hsivonen> | shepazu: thanks. I also read the logs at krijnhoetmer.nl. writing email now |
| 07:25 | <shepazu> | the speed with which he did so suggests a remarkably organized mind with a singular coherency of thought |
| 09:22 | <annevk3> | http://www.w3.org/mid/1e3451610903250034g69513bdvedd39f04dc270339⊙mgc o_O |
| 09:35 | annevk3 | was hoping hsivonen would run the sane script story campaign :) |
| 09:47 | <Hixie> | ok bed time nn |
| 09:47 | jgraham | wonders what the sane script story campaign is |
| 09:47 | <jgraham> | gn |
| 09:47 | <hsivonen> | nn |
| 09:48 | <annevk3> | jgraham, run scripts the same way in text/html regardless of whether they are SVG or HTML <script> elements |
| 09:49 | <jgraham> | Ah, OK. I thought by "sane" you might mean doing something other than html behaviour |
| 09:49 | <jgraham> | (which would be silly but could be described as "sane") |
| 09:50 | <jgraham> | (as the opposite to "insane script handling required by html") |
| 09:50 | <annevk3> | I'm not necessarily saying that's what in the spec now is insane. I just needed to name my campaign :p |
| 09:51 | <jgraham> | Well I agree doing anything inconsistent is insane |
| 09:51 | <jgraham> | More insane than just copying whatever HTML already does |
| 09:51 | <jgraham> | However weird |
| 10:13 | <jgraham> | For someone who thinks that it is a wate of time to discuss rsayre is really fast to reply |
| 10:17 | <MikeSmith> | hsivonen: you around? |
| 10:20 | <hsivonen> | MikeSmith: yes |
| 10:20 | <hsivonen> | MikeSmith: I saw the scrollback. Haven't processed the Schematron part yet. |
| 10:21 | <MikeSmith> | hsivonen: I made a minor change just to some message strings in the Assertions.java source |
| 10:21 | <MikeSmith> | built and tested it with my local v.nu instance and no problems and works as expected |
| 10:22 | <hsivonen> | MikeSmith: great. feel free to check in |
| 10:22 | <MikeSmith> | OK |
| 10:22 | <MikeSmith> | will do |
| 10:22 | <hsivonen> | MikeSmith: thanks! |
| 10:23 | <MikeSmith> | and I'm looking at the Assertions.java source now to try go see if I can add the label@for constraints |
| 14:42 | <Lachy> | it seems really strange that attempting to get the insertId attribute can potentially raise an exception. http://dev.w3.org/html5/webstorage/#dom-sqlresultset-insertid |
| 14:56 | <jgraham> | Should contentEditable elements be focusable? |
| 14:57 | <Philip`> | Hmm, my laptop's CPU fan seems to have become noisy, and the only way I can find to fix it is to run "perl -e'fork; 1 while 1'" for a minute so my CPU gets really hot and the fan goes to maximum speed, and then press the Tab or Caps lock or Q key, which makes the fan stop annoyingly whirring, and then it's fine once I let it cool down |
| 14:57 | jgraham | wonders how Philip` managed to find that methodology |
| 14:58 | Philip` | wonders if there's a more direct solution, that doesn't involve disassembling his laptop using screwdrivers that he doesn't have |
| 14:58 | <Philip`> | jgraham: It seemed a pretty obvious plan to me |
| 14:59 | <jgraham> | Philip`: Hit your laptop with a large hammer. Hard. It will soon stop making any annoying noise |
| 14:59 | <Philip`> | The whirring changed when I pressed down on the keyboard directly over the fan, so it seemed reasonable to try changing the fan speed and seeing if it spun itself back into a quiet state |
| 15:00 | <Philip`> | (The problem came back after I switched it off and on again, so I had an opportunity to discover the solution was repeatable) |
| 15:00 | <Philip`> | jgraham: Don't have a hammer |
| 15:01 | <Philip`> | and if I went to a store to purchase a hammer, I should purchase some screwdrivers too |
| 15:01 | <jgraham> | Philip`: A brick? A tin of beans? |
| 15:02 | <Philip`> | I suppose I could bash it with another laptop |
| 15:14 | <svl> | http://ilia.ws/archives/196-IE8-X-UA-Compatible-Rant.html :/ |
| 17:31 | <atw> | The chrome team is wondering about the behavior of window.postMessage() - since the destination window/iframe may not be loaded yet, what is the expected behavior if I post a message to a window whose contents aren't yet loaded. Should the message get dropped on the floor, or queued? |
| 17:31 | <atw> | Both Safari and Chrome just drop it on the floor now, which seems unideal. |
| 18:02 | <gsnedders> | Philip`: How many tags have mixed case names? |
| 18:03 | <jwalden> | atw: why is this a problem? I always understood postMessage to be for establishing communication with an already-loaded window, most particularly an iframe during the parent window's onload |
| 18:06 | <Philip`> | gsnedders: About six |
| 18:07 | <Philip`> | gsnedders: I see 4580419 tags matching [a-z], 594677 [A-Z], and 5585 matching both |
| 18:07 | <jwalden> | atw: that's also interoperable with Gecko, fwiw; IE is too much effort for me to test right now |
| 18:08 | <atw> | jwalden: Why would postMessage() not be useful for communicating with other windows? |
| 18:09 | <gsnedders> | Philip`: thx |
| 18:09 | <jwalden> | atw: um, please rephrase to ask what you meant to ask :-) |
| 18:09 | <atw> | Also, is the implication that onload on a parent window is invoked only after all iframes have been fully loaded? I have to admit I'm not 100% up on the semantics of onload. |
| 18:09 | <jwalden> | yes |
| 18:09 | <jwalden> | to the latter |
| 18:09 | <gsnedders> | Philip`: huh… "six" being the number of unique values? |
| 18:11 | <atw> | That use case makes sense to me (send messages on onload()) - I guess the intent of postMessage() is that the behavior is undefined if you are sending it to another window while that window's content is still loading? |
| 18:12 | <Philip`> | gsnedders: No, six being a number I made up off the top of my head, which turned out to not be a good approximation of 5585 |
| 18:12 | <jwalden> | "intent" I think is putting it a bit strongly, but I don't think it was considered a serious limitation |
| 18:12 | <jwalden> | atw: do consider that all the hash-and-poll hacks already required the target window to be loaded |
| 18:13 | <gsnedders> | Philip`: ah |
| 18:14 | <jwalden> | also seems to me that making early messages get queued is mostly unneeded complexity in the implementation, and sites can work around the "problem" without much trouble |
| 18:14 | <jwalden> | a limitation, but not pejoratively |
| 18:15 | <atw> | jwalden: Sure. We do that work for MessagePorts (queue messages before the port is started) so this seemed like an analogous situation, which is why the behavior surprised me. |
| 18:16 | <atw> | But I'm not arguing that it's unreasonable. |
| 18:17 | <jwalden> | messageports came along after I last really looked at postMessage, so I don't know the details of how they work |
| 19:22 | <Philip`> | gsnedders: "This gives a fair performance boost on the spec (~12s)" - you should run your tests on a slower computer, then you could easily get a ~24s performance boost from the same patch |
| 19:27 | <gsnedders> | :D |
| 20:44 | <gsnedders> | Man, I really am awesome at procrastinating. |
| 20:51 | <nessy> | lol |
| 20:53 | <jgraham> | gsnedders: Or you're just arrogant ;) |
| 20:58 | <annevk3> | svl, did you verify that? it sounds weird |
| 20:59 | <svl> | annevk3: I didn't. |
| 20:59 | <svl> | Just stumbled across it in the midst of doing other things |
| 21:00 | <annevk3> | atw, waiting for <iframe onload> seems like a long time; though I don't really have a better solution (other than the <iframe> pinging the parent) |
| 21:25 | <annevk3> | rubys1, while <b><i>x</b></i> is a somewhat simple example and "works", adding a character (e.g. <b><i>x</b>x</i>) already gives you a DOM that authors would not expect |
| 21:26 | <annevk3> | I'm not sure if it's worth distinguishing between the two as it's likely that the cost of implementing in validators would be so high that the resulting messages would be terribly confusing to authors. |
| 21:27 | <annevk3> | (And validators are already confusing. E.g. validator.nu is a multi-year project and still has a lot of error messages that are quite confusing.) |
| 21:27 | <annevk3> | (Not to speak of validator.w3.org...) |
| 21:29 | <annevk3> | As for "<meta charset=utf-8>". I think zcorpan suggested it might have been that older browsers just looked for the string "charset". That actually seems more plausible than that they tried to work with content that didn't work in any browser whatsoever. (And because they did that authors didn't have to care about quotes...) |
| 21:43 | <Philip`> | annevk3: Maybe a better example is <meta name=description content=an unquoted sentence> |
| 21:43 | <Philip`> | annevk3: It looks like about 1% of <meta name=description>s have that error |
| 21:43 | <Philip`> | (and about 1% of <meta name=keywords>s too) |
| 21:44 | <Philip`> | (Some of those are because people accidentally use fancy Word quotes, or put double quotes inside the double quoted attribute value, but I think many are from intentionally unquoted attributes) |
| 21:45 | <annevk3> | Philip`, what affect did that have on browsers? The ability to handle lots of attributes? |
| 21:45 | <annevk3> | effect, geez |
| 21:46 | <Dashiva> | Death to fancy quotes |
| 21:48 | Philip` | saw one site with two thousand attributes on its <meta name=keywords> |
| 21:49 | <Philip`> | annevk3: I wasn't thinking of the effect on authors - I was just thinking of it as evidence that unquoted attributes encourage authoring errors, and so perhaps they should be discouraged |
| 21:50 | <Dashiva> | Know of any cases where meta @keywords is actually used as keywords, and not just treated as normal text or ignored? |
| 21:51 | <Hixie> | Philip`: that's very common |
| 21:51 | <Hixie> | <meta name=keywords content=a, b, c, ... for megabytes> |
| 21:51 | <Hixie> | i had to make serious changes to my parser to handle this case |
| 21:51 | <annevk3> | Philip`, I thought rubys1 was talking about fallout |
| 21:52 | <annevk3> | oh help, <br> and 'clear' is brought up again on www-style |
| 21:53 | annevk3 | remembers a certain F2F where that was discussed for more than 10min |
| 21:53 | <Hixie> | only 10min? |
| 21:54 | <annevk3> | I'm being conservative here. My recollection has it on 1h :) |
| 21:54 | <Hixie> | that sounds more like it |
| 21:55 | annevk3 | goes to read AC minutes |
| 21:56 | annevk3 | didn't know AC meetings where also for chairs |
| 21:56 | <annevk3> | s/where/were |
| 21:57 | <annevk3> | hmm, I write English phonetically and I'm pretty bad at it too :) |
| 21:57 | <rubys> | Philip` got my intent. I agree that misnested closes are often indication of an error, and that dropping quotes can lead to errors... the line between the two is fuzzy. |
| 22:00 | <annevk3> | Historically the line has been pretty clear :) |
| 22:01 | <rubys> | ??? |
| 22:01 | <rubys> | not to me. |
| 22:01 | <annevk3> | I'm not that opposed to requiring quotes everywhere personally. It's an easy XSS target. However, seems a bit burdersome for existing content and XSS should likely be checked using dedicated tools (e.g. a public version of scanmus) as there are many other potential holes. |
| 22:02 | <annevk3> | rubys, quotes have always been optional and misnested inlines have always been disallowed |
| 22:02 | <rubys> | My problem is more basic than that: What would "requiring" mean? What does "disallowed" mean? |
| 22:03 | <rubys> | Will Opera refuse to show a page that doesn't meet one or the other criteria? |
| 22:03 | <rubys> | (that was rhetorical, the answer is "of course not") |
| 22:03 | <annevk3> | (right) |
| 22:03 | <annevk3> | That has also been pretty consistent from a historical perspective :) |
| 22:04 | <annevk3> | I was talking about authoring requirements. Much like the SVG WG was. |
| 22:04 | <rubys> | Is it best practice to nest corectly? To always use quotes? I can see arguments for both. |
| 22:06 | <annevk3> | I don't really know about best practice. Sounds fuzzy :) |
| 22:07 | <karlcow> | [17:54] <Dashiva> Know of any cases where meta @keywords is actually used as keywords, and not just treated as normal text or ignored? |
| 22:07 | <karlcow> | spotlight on mac os x |
| 22:07 | <annevk3> | If it's really that unclear, I was simply talking about what prior HTML specifications required from authors. E.g. HTML4. |
| 22:08 | <Hixie> | wilhelm_: any news on the timeout spec? |
| 22:09 | rubys | really, really, really didn't want to use the "alt" attribute as my example, which is a case where HTML5 attempts to legislate "best practices" in a way that differs from HTML4 |
| 22:09 | Hixie | wonders what to do with setTimeout() and company |
| 22:12 | <karlcow> | Yahoo too it seems if the claim is right http://help.yahoo.com/l/us/yahoo/search/ranking/ranking-02.html |
| 22:14 | <annevk3> | rubys, I'm not saying we can't make changes either way. As I said, I'd be happy with required quotes. I'm just saying that historically allowing unquoted attributes and disallowing misnested tags has been the way to go. |
| 22:15 | <gsnedders> | What's an example of something where all browsers interoperably break the spec? |
| 22:17 | <annevk3> | <datagrid> |
| 22:17 | <annevk3> | :) |
| 22:17 | <Hixie> | i don't think "don't implement any of it" counts as "breaking the spec" :-P |
| 22:17 | <annevk3> | (actually, I guess there are parsing differences in text/html) |
| 22:18 | <rubys> | gsnedders: http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.3 |
| 22:19 | <rubys> | In particular, shorthand markup. |
| 22:19 | gsnedders | was trying to avoid SGMLisms |
| 22:20 | <gsnedders> | rubys: Also, where in HTML 4.01 does it require an SGML parser to be used? |
| 22:20 | <gsnedders> | rubys: If there isn't such a thing, as I believe to be the case, then it isn't breaking the spec. |
| 22:21 | <rubys> | OK, here's a non GML HTML5 issue: "'Boolean attributes in HTML5 can't use the values "true" or "false" and I can't get myself to accept that fact." -- http://www.w3.org/QA/2009/03/a_rough_view_of_the_future.html |
| 22:23 | <annevk3> | I guess he never used HTML4 :) |
| 22:24 | gsnedders | would like a better thing which is certainly against the spec |
| 22:25 | <annevk3> | (Boolean attributes came pretty much straight from HTML4 although we removed the silly SGMLism that you specify the value rather than the attribute.) |
| 22:26 | <Hixie> | yeah that's not new in HTML5 |
| 22:27 | <gsnedders> | So PHP html5lib tokenizer is currently at 10.2s to tokenize the spec |
| 22:27 | <gsnedders> | Compared with 7.46s for Python |
| 23:04 | <Hixie> | gsnedders: what would be a helpful reply to your e-mail? |
| 23:05 | <gsnedders> | Hixie: Just answer the questions somehow |
| 23:05 | <gsnedders> | (That's useless, I know.) |
| 23:07 | <Hixie> | gsnedders: is there sample output anywhere? i don't have a file to pass it to test it. |
| 23:08 | <gsnedders> | Not really. Grab css3-namespaces, Bert's DB (see the postprocessor docs, it's linked there), and run that |
| 23:09 | <Hixie> | uris? |
| 23:10 | <gsnedders> | http://dev.w3.org/cvsweb/~checkout~/csswg/css3-namespace/Overview.src.html |
| 23:10 | <Hixie> | wait, you can't give a url |
| 23:10 | <Hixie> | how does this work |
| 23:11 | <gsnedders> | File uploads only |
| 23:12 | <Philip`> | gsnedders: You should spend some time optimising the Python version |
| 23:12 | <gsnedders> | Philip`: Nah |
| 23:12 | <gsnedders> | Philip`: You do that well enough |
| 23:12 | <Philip`> | gsnedders: just to give yourself a better target to aim for in the PHP implementation |
| 23:12 | <Hixie> | well i replied |
| 23:12 | <Hixie> | dunno how helpful my reply will be! |
| 23:12 | <Philip`> | gsnedders: But I've run out of ways to make it faster, so I was hoping you could try it instead :-p |
| 23:13 | <Hixie> | i recommend removing the python interpreter |
| 23:13 | <Hixie> | it seems like a big bottleneck |
| 23:13 | <gsnedders> | Nice conclusion :) |
| 23:37 | <Hixie> | hm, no ietf apparea minutes yet |