| 03:05 | <heycam> | TabAtkins_, what happened to author-ident in css3-values? (what grammar symbol should I use instead?) |
| 03:20 | <Yuhong> | http://www.w3.org/wiki/Evolution |
| 03:20 | <Yuhong> | I wonder what happened |
| 03:21 | <Yuhong> | http://www.w3.org/2001/tag/2011/12/evolution/ |
| 08:30 | <miChou> | Good morning/evening! :) |
| 08:32 | <jgraham> | (in India it is the afternoon) |
| 08:33 | <miChou> | does morning..evening does the trick then? :D |
| 08:33 | <odinho> | miChou: Yeah, good morning :-) |
| 08:34 | <jgraham> | In 'frisco it is the middle of the night :) |
| 08:34 | <miChou> | 1:34 to be more precise |
| 08:34 | <jgraham> | (I hear that people really don't like it if you call it 'frisco :) |
| 08:36 | <miChou> | TabAtkins_: ping? |
| 08:37 | <odinho> | jgraham: So that's why you do it? To spite'em? |
| 08:52 | <jgraham> | odinho: That and http://www.youtube.com/watch?v=VJ19ahNyM3I :) |
| 09:09 | <odinho> | jgraham: Sssss! |
| 09:17 | <jgraham> | Hmm, I am missing something about what happens if you do history.go(-1); history.go(-1) |
| 09:19 | <jgraham> | (alternative theory: the spec is missing something) |
| 09:19 | <jgraham> | (but at this juncture I will guess it is more likely me) |
| 09:22 | <gsnedders> | Do we file a bug on jgraham if he's wrong? |
| 10:40 | <zcorpan> | wonder if there's anything in http://necolas.github.com/normalize.css/ that can be changed in browsers/the spec |
| 13:28 | <odinho> | Hrmf. I can't find chromium nightly builds. |
| 13:28 | <odinho> | They're just gone from the old new place they were moved to. |
| 14:53 | <jgraham> | OK, I think I have current browser behaviour worked out |
| 14:53 | <jgraham> | In Opera, first navigation wins |
| 14:53 | <jgraham> | history.go(-1); history.go(-2) will take you back 1 |
| 14:54 | <jgraham> | In gecko/webkit last navigation wins so you will go back 2 |
| 14:54 | <jgraham> | *but* |
| 14:54 | <gsnedders> | There's always a but, isn't there? |
| 14:55 | <jgraham> | If you try to navigate to some undefined point in history last, gecko will ignore it, but webkit will still cancel the previous navigations |
| 14:55 | <jgraham> | So history.go(-2) history.go(3) with no forward history will go back 2 in gecko and do nothing in WebKit |
| 14:56 | <jgraham> | smaug____: ^ does that sound right? |
| 14:56 | <jgraham> | If the spec specifies this then I am skipping over the relevant part when I read it |
| 14:58 | <smaug____> | jgraham: sounds right |
| 14:58 | <smaug____> | (I mean the Gecko part) |
| 15:00 | <smaug____> | (though, I wonder if Gecko's shistory is sync in some cases... need to check) |
| 15:05 | <jgraham> | Hmm, and IE does something else again |
| 15:06 | <jgraham> | Maybe doesn't ignore anything |
| 15:07 | <smaug____> | fun |
| 15:07 | <jgraham> | So 21 years after the first web browser was released, we still don't have any operability at all on the fundamental navigation mechanism of the web platform |
| 15:08 | <jgraham> | Even though it is probably the simplest possible design |
| 15:09 | <gsnedders> | Did WorldWideWeb have back/forwards? |
| 15:11 | <smaug____> | Did NS2 have .history |
| 15:11 | <smaug____> | or was is it added to NS3 |
| 15:12 | <gsnedders> | Opera 2 seems to have back/forwards buttons, at least. |
| 15:15 | <jgraham> | Well The string "back" appears in the binary. http://www.w3.org/History/1994/WWW/Journals/CACM/screensnap2_24c.gif shows a "navigate" menu |
| 15:15 | <smaug____> | "WorldWideWeb's navigation panel contained Next and Previous buttons that would automatically navigate to the next or previous link on the last page visited" |
| 15:15 | <jgraham> | Ah yeah |
| 15:16 | <jgraham> | Anyway, so we have had quite a while to get this stuff right :) |
| 15:24 | <Hixie> | jgraham: fwiw the behaviour of the back button and history.back() in the spec is intended to be a careful choice based on tests and thought, it's not supposed to be incompatible with the web |
| 15:25 | <Hixie> | jgraham: however, it is indeed an area with low interop |
| 15:25 | <Hixie> | jgraham: so if there is content that isn't compatible, that'd be good to know |
| 15:25 | <jgraham> | Hixie: I have no idea about *content*. At the moment I am trying ot figure out what browsers do and what the spec says :) |
| 15:26 | <jgraham> | Hixie: Can you give me a high level overview of what the intent of the spec is? |
| 15:27 | <jgraham> | Because this stuff is not very easy to follow |
| 15:27 | <jgraham> | Unless you know what the expected outcome is |
| 15:30 | <Hixie> | i can in a few minutes, can't pay attention right now |
| 15:30 | <jgraham> | (afaict, IE has some strange behaviour where if you do something like .go(-1) .go(-1) .go(2) .go(-1) it will ignore the .go(2) because that would take you back to where you first started and you will end up .go()ing -3) |
| 15:30 | <jgraham> | Hixie: No problem |
| 15:31 | <jgraham> | (but I am hoping that my test is broken because that would be crazy) |
| 15:31 | <Hixie> | iirc it's async, and only the last takes effect, but i can give you a more correct answer in a bit |
| 15:32 | <jgraham> | I'm pretty sure it's async |
| 15:32 | <jgraham> | I haven't yet worked out why only the last would take effect |
| 15:32 | <jgraham> | If that is indeed what happens |
| 15:34 | <Hixie> | sorry, only the first, assuming you cross a document boundary after the first |
| 15:34 | <Hixie> | (still not fully paying attention) |
| 15:38 | <Hixie> | ok let's see |
| 15:39 | <Hixie> | so anything that happens happens after the script has finished executing, because go() and back() et al do all their work in a queued task |
| 15:39 | <Hixie> | they have their own special task source, the history traversal task source |
| 15:40 | <Hixie> | part of the pushState() and document.open() methods empties that queue |
| 15:40 | <Hixie> | as does "update the session history with the new page" |
| 15:40 | <Hixie> | and navigating to a frag id |
| 15:41 | <Hixie> | but it doesn't seem it gets emptied by traversal |
| 15:41 | <jgraham> | Right, because this is entry update |
| 15:41 | <jgraham> | So "update the session history" specifically doesn't empty the queues |
| 15:42 | <Ms2ger> | Good morning, Whatwg |
| 15:42 | <Hixie> | er yeah, sorry, not empty |
| 15:42 | <Hixie> | cleans up a bit :-) |
| 15:43 | <Hixie> | assuming the first go(-1) crosses a doc boundary, then all the subsequent ones get ignored, per spec |
| 15:43 | <jgraham> | Hmm, I lost something somewhere |
| 15:44 | <Ms2ger> | Your car keys? |
| 15:44 | <Hixie> | though maybe they would technically still be in the queue when you go back to the doc, heh |
| 15:44 | <jgraham> | Isn't traversal the case where the algorithm is initiated for /entry update/? |
| 15:44 | <Hixie> | "traverse the history" happens for a number of things |
| 15:45 | <Hixie> | go(), pushState(), navigation, etc |
| 15:45 | <Hixie> | maybe not pushState() |
| 15:45 | <jgraham> | I am specifically wondering about .go() in this case |
| 15:45 | <Hixie> | go() definitely invokes it, it's the last step of go()'s algorithm |
| 15:46 | <Hixie> | looks like we should be emptying this queue somewhere |
| 15:47 | <Ms2ger> | krijn, http://krijnhoetmer.nl/irc-logs/ doesn't seem to update, though the pages ere there |
| 15:47 | <Hixie> | that we're not yet doing so |
| 15:47 | <Ms2ger> | *are |
| 15:47 | <krijn> | Hmpf |
| 15:48 | <krijn> | Ms2ger: updated |
| 15:48 | <Ms2ger> | That was quick :) |
| 15:48 | <krijn> | My cronj...Windows Task Schedule thingy...wasn't running |
| 15:48 | <jgraham> | Hixie: OK, so the intent of the spec is to match Opera; i.e. first wins? |
| 15:49 | <Hixie> | jgraham: dunno if it matches opera, but first is supposed to win as far as i can tell |
| 15:50 | <Hixie> | jgraham: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=18626 |
| 15:51 | <jgraham> | Hixie: OK, thank you. That is clearer |
| 15:51 | <jgraham> | and gives me something to aim for until averyone else decides that they don't agree with this model ;) |
| 15:52 | <Hixie> | jgraham: does it match mozilla? |
| 15:53 | <smaug____> | jgraham: what? the first go() wins? |
| 15:53 | <jgraham> | Hixie: No one matches |
| 15:53 | <jgraham> | smaug____: That is apparently the intent of the spec |
| 15:54 | <Hixie> | either the step that cleans the task source in the navigation algorithm should be moved to the traverse algorithm, or a step should be placed in the "by a delta" algorithm should have it... |
| 15:54 | <Hixie> | jgraham: how do they differ? |
| 15:54 | <Hixie> | this is one of those areas where i'm pretty sure i was trying to match either gecko or webkit, probably gecko |
| 15:55 | <jgraham> | Hixie: In Gecko last wins, unless it would navigate outside the session history in which case you work backward through the list until there is a valid one |
| 15:55 | <jgraham> | so .go(-1) .go(2) with no forward history would be like .go(-1) |
| 15:55 | <Hixie> | http://hixie.ch/tests/adhoc/dom/level0/history/ is where i put my tests, though it looks like i didn't save many |
| 15:56 | <Hixie> | ah so gecko tests the validity sync, then queues a task, interesting |
| 15:56 | <jgraham> | In WebKit last wins always and if it doesn't do anything there is no navigation |
| 15:56 | <Hixie> | so webkit essentially clears the task source each time |
| 15:56 | <smaug____> | what in the spec says go(-1) should win? |
| 15:56 | <jgraham> | In Opera first wins |
| 15:57 | <jgraham> | In i.e. all navigations are taken into account so .go(-2) .go(-1) takes yopu back 3 |
| 15:57 | <jgraham> | But, if my tests are not broken (I think they might be) anything that would lead to no overall navigation is ignored |
| 15:57 | <jgraham> | so .go(-2) .go(2) .go(-1) is like .go(-3) not like .go(-1) |
| 15:58 | <Hixie> | what about go -2 -2 -2 -2 when you only have 2? |
| 15:58 | <Hixie> | does it crash? |
| 15:59 | <jgraham> | IE? |
| 15:59 | <Hixie> | y |
| 15:59 | <Ms2ger> | Does it print random numbers? :) |
| 16:01 | <Hixie> | afk brb |
| 16:01 | <jgraham> | Just ends up on the first page in history afaict |
| 16:06 | <jgraham> | Hixie: I don't know who is supposed to pass your tests, but gecko ends up in the wrong history position, webkit is in an infinite reload loop and Opera fails |
| 16:06 | <jgraham> | So if the spec is based on those tests, it doesn't also follwo browsers ;) |
| 16:12 | <dglazkov> | good morning, Whatwg! |
| 16:17 | <Hixie> | jgraham: maybe it was a combination of the best parts :-) |
| 16:18 | <Hixie> | jgraham: anyway, IE's behaviour seems obviously bad (why compare against something you're not going to execute against) |
| 16:19 | <Hixie> | jgraham: are you testing with multiple traversals from multiple frames? |
| 16:19 | <Hixie> | jgraham: which wins if you have e.g. a subframe go back then a parent go back, all in one task? |
| 16:19 | <Hixie> | jgraham: seems to me the "first wins" model is the sanest and easiest to reason about |
| 16:42 | <hendry> | hsivonen: hi, do you know how I can set location.search up without making the page reload? https://github.com/kaihendry/Greptweet/issues/20#issuecomment-7875290 |
| 16:43 | <jgraham> | Hixie: I have only tested top level browsing contexts without children so far |
| 16:45 | <miChou> | hi TabAtkins_, you 'around? |
| 16:49 | <TabAtkins_> | heycam|away: We killed it pending resolution of some issues around case-normalizing. At minimum, we're going to make author-defined idents do ascii-case-folding, to match CSS-defined identifier, but we may do unicode-case-folding as well, if we can define an acceptable form that's friendly to atomic string comparison. |
| 16:49 | <TabAtkins_> | heycam|away: That's a long way of saying "just use <ident>". |
| 16:49 | <TabAtkins_> | miChou: pong |
| 16:50 | <TabAtkins_> | Ms2ger: Beyond UA trickery and some quirks mode stuff that *everyone* does, what are examples of other browsers lying to sites? |
| 16:53 | <miChou> | TabAtkins_: got a question regarding <br>-s and fragmentation. If I do something like <br style="display: block; width: 1px; height: 1px; break-after: column (or region, or page)"> should it break the column(/region/page), or not? (that is, beside the line breaking that implicitly occurs) |
| 16:53 | <miChou> | I sent an email to www-style a week or so ago but did not get a definitive answer :) |
| 16:54 | <TabAtkins_> | miChou: Hm, I am not the right person to ask about fragmentation, but let me dig around and see if I can answer this. |
| 17:08 | <miChou> | TabAtkins_: thanks a bunch! |
| 17:12 | <TabAtkins_> | miChou: Okay, yeah, it should create a break. |
| 17:21 | <miChou> | TabAtkins_: ok, good to know. I'll go file some browser bugs :> |
| 17:25 | <Hixie> | what's the canonical url for html parsing tests that i should give someone who is writing an html parser? |
| 17:27 | <Ms2ger> | html5lib on code.g.c |
| 17:27 | <Hixie> | http://code.google.com/p/html5lib/source/browse/#hg%2Ftestdata%2Ftokenizer and http://code.google.com/p/html5lib/source/browse/#hg%2Ftestdata%2Ftree-construction ? |
| 17:27 | <Hixie> | is there documentation for the test format? |
| 17:27 | <Ms2ger> | ... what is this thing you speak of? |
| 17:28 | <Hixie> | http://wiki.whatwg.org/wiki/Parser_tests ? |
| 17:28 | <Ms2ger> | Oh good |
| 18:01 | <jgraham> | TabAtkins: Excluding the most common ways that browsers lie to sites in "ways browsers lie to sites" is just bizzare |
| 18:01 | <jgraham> | But even if you do exclude those, Chrome has shipped DOM APIs for features that it didn't actually have |
| 18:01 | <TabAtkins> | jgraham: The point was in reference to individual browsers lying, not everyone lying in the same way, which is much less troublesome. |
| 18:02 | <jgraham> | But everyone doesn't lie in the same way in their UA string, for example |
| 18:03 | <TabAtkins> | Sure, but who cares about UA strings? It's irrelevant to the philosophical question of "will a new feature detection mechanism work?". |
| 18:04 | <TabAtkins> | We got rightly complained at for shipping APIs before the feature was ready, and we're a bit more careful about that now. |
| 18:04 | <TabAtkins> | The examples I know of were just sloppy coding, not deliberate lies. |
| 18:04 | <jgraham> | Since UA strings are an existing example of a feature detection mechanism, and one in which browsers are still forced to lie, it does seem somewhat relevant |
| 18:05 | <jgraham> | Not sure how you managed to ship a whole dom implementation of <details> with no UI through sloppy coding, but my point is not to dwell on the missteps of others |
| 18:05 | <TabAtkins> | You could argue that, but I don't think it's significant enough. It's far removed from actual *feature* testing, so it's no wonder that it gets polluted. |
| 18:07 | <jgraham> | We so far we have tried UA strings and hasFeature and feature detection, and they have all been gamed and are all abused by authors |
| 18:09 | <TabAtkins> | Yes, because UA strings are *very* far removed from the features we're trying to detect, so they corrupt very easily. hasFeature is still somewhat removed from the actual feature (level of removal varies on how granular the strings are defined) as whether you return a boolean for a string has no technical connection to the implementation of the feature. |
| 18:09 | <TabAtkins> | hasFeature is, I think, *less* corrupted than UA strings, but still too much to be usable. |
| 18:09 | <TabAtkins> | (Insofar as they were usable in the first place.) |
| 18:10 | <TabAtkins> | supports(), on the other hand, is tightly coupled to the feature, probably as tightly coupled as we can get without actual testing. The easiest implementation is to just hand it to your CSS parser and see if it's recognized, and what you parse it tightly attached to what you implement and are willing to expose to the world. |
| 18:10 | <TabAtkins> | (Again, very occasional missteps in this, but they're quite rare.) |
| 18:11 | <TabAtkins> | Plus, the granularity is perfect, because you can test the *exact* syntax you're planning to use. |
| 18:12 | <TabAtkins> | This suggests that supports() will be less corrupted than hasFeature() was. There's still a possibility that "less" is still "too much", but we'll see. |
| 18:12 | <TabAtkins> | If this fails, then feature detection in the browser is basically impossible. |
| 18:12 | <jgraham> | People won't test the exact thing they will use |
| 18:13 | <jgraham> | They will test some thing that is a good proxy for what they want to use in some particular contempary browser |
| 18:13 | <jgraham> | This happens all the time with jaascript feature detection |
| 18:13 | <TabAtkins> | Not for all cases, no - that would be way too verbose. But you can take some representative line from you code and use it exactly. |
| 18:14 | <jgraham> | Anyway, I don't particularly care about @supports |
| 18:14 | <jgraham> | I don't expect it to work well but there is no way I will convince you of that |
| 18:15 | <jgraham> | It is nevertheless distressing that you are going around making crazy statements about browsers not lying to make sites work |
| 18:16 | <TabAtkins> | I'm sorry that you're ignoring my clarification about that statement. I assumed it was obvious in context, but it may not have been clear. |
| 18:16 | <jgraham> | Which clarification? The fact that you were ignoring multiple ways that browsers lie? |
| 18:16 | <TabAtkins> | (Assuming you read the context at all. The line by itself, as Ms2ger quoted, is incorrect.) |
| 18:17 | <jgraham> | I read the context |
| 18:17 | <TabAtkins> | My line starting from "The point was in reference...". Don't be purposely dense. |
| 18:18 | <Ms2ger> | Now you're just being a dick |
| 18:18 | <jgraham> | I'm not being. I don't see how even basic stuff like UA strings is "everyone lying in the same way" |
| 18:19 | <TabAtkins> | Ms2ger: ffs |
| 18:20 | <TabAtkins> | jgraham: I can go further into my reasoning, but I think I explained well enough above, and it's irrelevant anyway - you're less optimistic about trying this kind of thing again, and that's okay. |
| 18:20 | <jgraham> | Chrome pretends to be Gecko, Safari and Mozilla. Opera claims to be an older version of Opera. Firefox claims to be Mozilla. etc. |
| 18:20 | <TabAtkins> | If you were trying to block the feature, I'd be more concerned about convincing you, but if it's just a personal opinion, you're allowed to hold it. ^_^ |
| 19:00 | <Hixie> | TabAtkins: btw re @supports and co, i like that it is designed with the hasFeature() lessons in mind. i hope it works, if it does we might be able to reuse this design in the future. |
| 19:04 | <zcorpan> | i expect @supports will be used to test what codec to use in webrtc |
| 19:05 | <Ms2ger> | if (!CSS.supports("MP3")) { alert("Wrong browser!"); } |
| 19:05 | <Ms2ger> | Something like that? |
| 19:06 | <TabAtkins> | More like "if( CSS.supports('-moz-foo') { /* use a format that mozilla supports */ }". |
| 19:07 | <zcorpan> | right, except not -moz-, just a standard property that mozilla happens to support and iPhone default browser doesn't, or whatever |
| 19:07 | <Ms2ger> | Oh, looks like we support iframe sandbox now |
| 19:08 | <Ms2ger> | if (CSS.supports("document.all")) |
| 19:08 | <TabAtkins> | That'll be false everywhere. ^_^ |
| 19:09 | <zcorpan> | (the only application of -o-object-fit i've seen in the wild is browser-sniffing for opera of the version where that was added, for an entirely different purpose than the property itself) |
| 19:25 | <TabAtkins> | Hixie: Someone internally is asking for window.devicePixelRatio to be standardized, for the purpose of sizing <canvas> properly. Is this necessary if we expose the HD stuff? |
| 19:26 | <Hixie> | no |
| 19:26 | <Hixie> | it's exposed as part of the HD stuff |
| 19:27 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#dom-screen-canvasresolution |
| 19:28 | <TabAtkins> | Excellent, thanks. |
| 19:28 | <dglazkov> | smaug____: will tomorrow at 2:00pm work for you? |
| 19:29 | Hixie | goes to add a reference and finds it has 19 editors |
| 19:29 | Hixie | decides to omit that editor list |
| 19:29 | <smaug____> | dglazkov: looking at the schedule ... |
| 19:29 | <smaug____> | dglazkov: "3pm-4pm: Web components planning " |
| 19:30 | <smaug____> | that would be mozilla only stuff... |
| 19:30 | <smaug____> | let me ask someone about the previous thing... |
| 19:32 | <smaug____> | dglazkov: 2pm should be ok |
| 19:32 | <smaug____> | dglazkov: blake should be around too |
| 19:33 | <Hixie> | lang=jp isn't valid? |
| 19:33 | <smaug____> | dglazkov: ah, saw your email... answering.. |
| 19:33 | <Hixie> | validator.nu says 'The language subtag "jp" is not a valid ISO language part of a language tag' |
| 19:37 | <Hixie> | oh it's ja |
| 19:50 | <dglazkov> | smaug____: great, thank you! |
| 20:48 | <zcorpan> | TabAtkins: so i want to define hashless and unitless at tree-construction rather than at tokenizer. there's "If the current declaration is grammatically valid, append it to the value of the current rule." so i'd need to rewrite the primitives before that (i guess in "consume a primitive") |
| 20:49 | <zcorpan> | and i guess i need to set a flag in declaration mode when seeing the ident token, if it's one of the quirky properties |
| 20:51 | <TabAtkins> | zcorpan: Alternately, rewrite it at that "grammatically valid" check-point. |
| 20:51 | <TabAtkins> | Check if it's valid. If not, swap out the tokens for their quirks-mode equivalents, and check again. |
| 20:52 | <zcorpan> | yeah but that seems more annoying to spec :-) |
| 20:55 | <TabAtkins> | Yeah, setting a flag in declaration mode and converting tokens in declaration-value mode might work. |
| 20:56 | <TabAtkins> | I can just put the hooks in directly, if you'd like. |
| 20:56 | <TabAtkins> | Also: yay, I can remove the scinot flag and just have it on all the time now! |
| 20:59 | <zcorpan> | hooks would be nice |
| 21:01 | <TabAtkins> | Just describe what would be convenient for you to use, or alternately, define some hooks on your side so I can just directly reference them. |
| 21:02 | <zcorpan> | yeah that works |
| 21:02 | <zcorpan> | i wonder when the flags should be unset again |
| 21:02 | <zcorpan> | when entering the declaration mode next time? |
| 21:03 | <TabAtkins> | Presumably just all the states that exit "declaration parsing". |
| 21:04 | <TabAtkins> | That is, the error states in after-declaration-name, and the ending states in declaration-value. |
| 21:07 | <zcorpan> | yeah |
| 21:27 | <zcorpan> | TabAtkins: i think it would be better to just put the quirks in the parser spec directly |
| 21:29 | <zcorpan> | only annoying thing is that it needs to check the names of properties and functions |
| 21:31 | <zcorpan> | maybe i can try writing a patch for the parser |
| 21:51 | <TabAtkins> | Feel free. I think it would be workable for the quirks spec to define the set of properties that need quirk handling, and the way in which each is handled. |
| 21:51 | <TabAtkins> | But I'm okay with Syntax just handling the whole thing. My ideal handling of it would just be taking the part I'd want in the quirks spec and putting it in an appendix. |
| 21:53 | <zcorpan> | TabAtkins: there's an </h4> missing (top-level mode) |
| 21:55 | <TabAtkins> | fixed |
| 21:55 | <zcorpan> | v.nu complained about some other errors in the source document also |
| 22:02 | <TabAtkins> | Ah, yeah, more markup errors. Fixed. |
| 22:32 | <zcorpan> | TabAtkins: http://simon.html5.org/dump/css3-syntax/ has the original source file (before the fixing of markup errors) and the other file is with quirks added (i didn't add the list of properties though) |
| 22:36 | <TabAtkins> | Ah, so I can just diff it? |
| 22:37 | <zcorpan> | yeah |
| 22:42 | <zcorpan> | now i'm gonna sleep. but i'll read the logs tomorrow so just dump comments here if you have any :-) |
| 22:43 | <zcorpan> | nn |
| 23:09 | <heycam> | TabAtkins, ok thanks (will use <ident>) |
