| 00:01 | <AryehGregor> | Why is <form action=""> invalid? |
| 00:04 | <othermaciej> | jamesr: only if they are a complete document |
| 00:04 | <othermaciej> | (I<O) |
| 00:04 | <othermaciej> | er, IMO |
| 00:19 | <Philip`> | AryehGregor: Probably because it doesn't do what you should expect it to do |
| 00:19 | <AryehGregor> | Philip`, because it ignores <base>, or something else? |
| 00:19 | <AryehGregor> | It's equivalent to just <form>, right? |
| 00:19 | <Philip`> | (It's the document's address, not the document's current address) |
| 00:19 | <Philip`> | (so it's not the same as resolving the relative URL "") |
| 00:20 | <Philip`> | Yeah, <form> seems to be the same |
| 01:59 | <Hixie> | TabAtkins: yt? |
| 02:01 | <TabAtkins> | Hixie: Yup |
| 02:01 | <Hixie> | cool |
| 02:01 | <Hixie> | so about the CSS Element Reference Identifiers thing |
| 02:01 | <Hixie> | i'm fine the way it is |
| 02:02 | <Hixie> | just wanted to exlpain where i was coming from on the first thing |
| 02:02 | <TabAtkins> | That's cool. |
| 02:02 | <Hixie> | which is: |
| 02:02 | <Hixie> | isn't it any element that is a replaced element that you can use here? |
| 02:02 | <Hixie> | or something like that? |
| 02:03 | <TabAtkins> | Maybe? My brain tells me there was some reason why replaced elements in general weren't a good thing to use, but I don't remember what the reasoning was. |
| 02:04 | <TabAtkins> | I think maybe it's that something like a detached iframe isn't rendered, but using it in element() would require it to be? |
| 02:05 | <Hixie> | i dunno |
| 02:05 | <Hixie> | from the html side i don't see anything special about these elements |
| 02:05 | <Hixie> | it seems the specialness is a rendering-side thing |
| 02:05 | <Hixie> | so i figured there might be some more generic thing on the rendering side that you could use |
| 02:05 | <Hixie> | if there isn't, then that's fine :-) |
| 02:05 | <TabAtkins> | Yeah. I know that the criteria I used was "all the relevant display information is available without doing a layout". |
| 02:06 | <TabAtkins> | I just don't remember precisely why I chose that criteria. |
| 02:07 | <TabAtkins> | I should ask for impl feedback on the list, to see if it's a reasonable sort of thing. |
| 02:08 | <Hixie> | let me know if it should change again, obviously |
| 02:08 | <Hixie> | i'm fine with it the way it is |
| 02:08 | <TabAtkins> | kk |
| 02:08 | <Hixie> | just thought i'd mention this |
| 02:27 | <othermaciej> | TabAtkins: what are the elements where all relevant display information is available without doing a layout? |
| 02:27 | <TabAtkins> | img, video, and canvas |
| 02:27 | <othermaciej> | so when you say "layout" are you excluding style resolution? |
| 02:27 | <othermaciej> | (since that is necessary to determine their size and aspect ratio) |
| 02:27 | <TabAtkins> | They all have intrinsic sizes which are used when detached. |
| 02:28 | <othermaciej> | img may not have an intrinsic size if it points to SVG |
| 02:28 | <othermaciej> | or other scalable formats |
| 02:29 | <TabAtkins> | That's handled by the spec. Replaced elements have a default sizing area of 300x150. |
| 02:29 | <othermaciej> | svg also requires a layout of the "inside" part to the same extent as iframe |
| 02:29 | <TabAtkins> | That's true. |
| 02:30 | <TabAtkins> | So then perhaps <iframe>s are indeed okay. |
| 02:31 | <othermaciej> | (I don't have enough of the context to understand why restrictions are useful) |
| 02:31 | <TabAtkins> | Yeah, that's why i specifically pinged some of the FF people in the www-style thread, since they've already implemented it. |
| 02:32 | <TabAtkins> | (I'm out for the day now.) |
| 02:32 | <othermaciej> | later! |
| 07:00 | <hsivonen_> | Wow. the edits I made to the HTML5 video article on Wikipedia yesterday haven't been reverted by the usual suspect! |
| 07:01 | <tw2113> | take away their bacon |
| 07:15 | <othermaciej> | now I am intrigued |
| 07:16 | <othermaciej> | hsivonen: I see recent edits from you, but nothing reverting them, in the history |
| 07:16 | <othermaciej> | am I missing something? |
| 07:16 | <othermaciej> | oh |
| 07:16 | <othermaciej> | you said "haven't" |
| 07:17 | <othermaciej> | but now I wonder who the usual suspect is and what they have reverted in the past |
| 07:20 | <hsivonen> | othermaciej: the reverter had wanted to say that Theora support in Safari is "No" even though there are other cases in the table where installing codecs into a system media framework gets the "Depends" color |
| 07:20 | <othermaciej> | it looks like the table is still inconsistent |
| 07:21 | <hsivonen> | othermaciej: H.264 for Konqueror and Epiphany or something else? |
| 07:21 | <othermaciej> | for example it says "No" for H.264 in Knoqueror but "Depends" for Epiphany, even though both can use GStreamer |
| 07:21 | <tw2113> | i stand by my bacon comment |
| 07:21 | <othermaciej> | unless I misunderstand the situation |
| 07:21 | <hsivonen> | othermaciej: yeah, that looks bogus, but I didn't fix it because I didn't have time to verify yesterday |
| 07:21 | <othermaciej> | also there is a WebM QuickTime component, it appears |
| 07:21 | <othermaciej> | so unless for some reason that does't work in Safari, it should be a "Depends" |
| 07:22 | <hsivonen> | othermaciej: does the WebM component work in Safari now? last I tried, the December release didn't work in Safari. It just managed to confuse canPlayType |
| 07:22 | <othermaciej> | what would probably make the most sense is a column indicating whether that particular browser supports format pluggability |
| 07:23 | <hsivonen> | IIRC, they even said the December release was encode-only and didn't support decode properly yet |
| 07:23 | <othermaciej> | I'm also not clear on the distinction between "Manual Install" and "Depends" |
| 07:23 | <othermaciej> | ok, it might be that whatever is out does not work yet |
| 07:24 | <othermaciej> | I also recall that Opera uses GStreamer on at least some platforms, so is presumably format-extensible on those |
| 07:24 | <hsivonen> | othermaciej: I think "supports installable codecs and has codec Foo available" is much more informative that "support installable codecs" |
| 07:24 | <hsivonen> | othermaciej: the edit history of the page claims that Opera removed that pluggability |
| 07:24 | <hsivonen> | othermaciej: I have no idea if they really did. I suppose foolip would know. |
| 07:24 | <othermaciej> | it certainly is, though it's hard to parse what "Depends" means |
| 07:25 | <othermaciej> | I wonder also why Internet Explorer says "No" for "Others" |
| 07:25 | <hsivonen> | I think the "Others" column is entirely useless |
| 07:25 | <hsivonen> | othermaciej: the reference points to Dean's blog post |
| 07:26 | <hsivonen> | which, IIRC, said they'll allow WebM if installed but not arbitrary stuff |
| 07:26 | <othermaciej> | I was going to ask if that is actually true (would be extremely weird to support Media Foundation plugins but only whitelisted to one type!) but then I realized that is irrelevant for Wikipedia purposes |
| 07:27 | <hsivonen> | hmm. actually the reference is to a different blog post |
| 07:27 | <hsivonen> | othermaciej: I don't know if it is actually true |
| 07:27 | <othermaciej> | in the cited blog post it does say "In its HTML5 support, IE9 will support playback of H.264 video only." |
| 07:27 | <hsivonen> | but yeah, wikitruth is rather frustrating |
| 07:28 | <othermaciej> | but clearly WebM is a counter-example |
| 07:31 | <hsivonen> | othermaciej: IIRC, there's another blog post by Dean that seems to suggest they'd allow WebM pluggability but not Theora pluggability |
| 07:32 | <hsivonen> | othermaciej: I don't have a link at hand and I don't know what they shipped |
| 07:32 | <othermaciej> | this post: http://blogs.msdn.com/b/ie/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx |
| 07:32 | <hsivonen> | maybe someone should make a Media Foundation component for Ogg/Theora |
| 07:32 | <othermaciej> | claims that VP8 will be supported if a codec is installed |
| 07:32 | <othermaciej> | but it doesn't really make clear if that's exclusive |
| 07:34 | <hsivonen> | othermaciej: fwiw, from quick testing, it seems at least plausible that Konqueror is so broken that codec pluggability is semi-random |
| 07:35 | <othermaciej> | heh |
| 07:35 | <hsivonen> | othermaciej: so it's not a given that the Konq/Epiphany discrepancy is wrong |
| 07:36 | <hsivonen> | anyway, even if I found a way to make Konq actually play H.264, it would be Original Research, which would be inadmissible |
| 07:36 | <othermaciej> | that is true |
| 07:36 | <othermaciej> | you'd need to convince someone to blog about it before it would be admissible |
| 07:39 | <hsivonen> | in general, video support in Konqueror is very, very broken |
| 07:52 | <hsivonen> | hah. Wikipedia has an annotation for [non-primary source needed] |
| 07:52 | <hsivonen> | they count W3C Bugzilla as a primary source about HTML5 bugginess |
| 07:53 | <othermaciej> | so wait, a w3c bug would be original research, but a blog post about it wouldn't be? |
| 07:53 | <othermaciej> | or are blogs excluded for some other reason? |
| 07:54 | <hsivonen> | othermaciej: not original research but a primary source :-) |
| 07:54 | <hsivonen> | the Wikipedia approach to sources is just weird, though |
| 07:55 | <othermaciej> | are primary sources bad? |
| 07:55 | <hsivonen> | othermaciej: http://en.wikipedia.org/wiki/Wikipedia:No_original_research#Primary.2C_secondary_and_tertiary_sources |
| 07:55 | <othermaciej> | "primary sources are permitted if used carefully" |
| 07:56 | <othermaciej> | I hate rules that say "be careful" |
| 07:56 | <othermaciej> | that's not a useful guideline, it just makes you feel bad if you make a mistake |
| 07:56 | <Hixie> | sicking: your second e-mail is very confusing, i think due to your use of the word 'focus' for several distinct yet concepts, and possibly due to a misunderstanding about what the APIs do |
| 07:56 | <Hixie> | sicking: but i'm not sure what you meant so it's hard to say |
| 07:57 | <sicking> | Hixie: i could be talking out of my ass for sure |
| 07:58 | <Hixie> | so i think there are two main problems that they are trying to solve here |
| 07:58 | <Hixie> | or two main problem areas, more than two actual distinct problems |
| 07:59 | <Hixie> | the first area is about focus. the need is to be able to draw a focus ring in whatever fashion the OS wants, or let the author do it as he wishes, if he wishes to do it in a fancy way and the user doesn't have special focus ring needs |
| 07:59 | <Hixie> | the api is designed to basically have drawFocusRing() work like stroke(), but it only does anything if the given element is focused |
| 07:59 | <sicking> | Hixie: also, it draws with a OS-specific style, right? |
| 07:59 | <Hixie> | which means you can do if (c.drawFocusRing(element, true)) { c.stroke() } |
| 08:00 | <sicking> | hmm.. second argument in spec isn't a bool |
| 08:00 | <Hixie> | spec is out of date |
| 08:00 | <Hixie> | which would draw nothing if element wasn't focused, and otherwise would draw either an OS ring if the user needs a special style, or the author's strokeStyle otherwise |
| 08:01 | <Hixie> | let me regen with the suggested edits, hold no |
| 08:01 | <Hixie> | on |
| 08:01 | <Hixie> | now the second thing is the magnification accessibility ui |
| 08:01 | <Hixie> | this has to follow focus, for widgets like checkboxes, and for widgets with a selection or a caret, follow the selection or caret |
| 08:02 | <sicking> | Hixie: err.. if you don't give it any coordinates, where does it draw? |
| 08:02 | <Hixie> | current path |
| 08:02 | <sicking> | ah |
| 08:02 | <Hixie> | so for the former case, checkboxes and buttons and so on, you want it to just automatically do it if drawFocusRing() did something (i.e. if the element is focused) |
| 08:02 | <Hixie> | in the latter case, selection/caret, you apparently need to give a rect of the selection/caret, and this is what setSelectionCaretRectWhateverItIsCalled() is for |
| 08:03 | <Hixie> | spec is regenned if you want to see the new text |
| 08:03 | <sicking> | Hixie: right, so my suggestion is that drawFocusRing should by default draw+call setSelectionCaretRect |
| 08:04 | <sicking> | Hixie: but you can opt out, or at least override that, and call setSelectionCaretRect yourself |
| 08:04 | <sicking> | Hixie: and just get the drawing part |
| 08:04 | <Hixie> | that's what the spec has now, essentially -- it moves the magnifier unless you call setSelectionCaretRect in the same task |
| 08:05 | <Hixie> | another way to put it is it waits until the event loop spins (the rendering happens) and moves the magnifier to the last place that wanted it moved |
| 08:05 | <Hixie> | the current text isn't perfectly clear on this, i wasn't able to come up with a good way to say that yet |
| 08:05 | <Hixie> | i'll probably tweak it later to be clearer |
| 08:05 | <sicking> | Hixie: http://dev.w3.org/html5/2dcontext/ still isn't updated |
| 08:05 | <Hixie> | yeah i'm not comitting these changes, rich would lynch me |
| 08:05 | <Hixie> | look at the whatwg copy |
| 08:06 | <Hixie> | (in general i don't ever recommend looking at the w3c copy, it has all kinds of problems of various kinds) |
| 08:06 | <Hixie> | (s/copy/copies/ being one of the problems!) |
| 08:06 | <sicking> | Hixie: so i'm still not sure what part of my email is confused |
| 08:07 | <Hixie> | it might just be me being confused |
| 08:07 | <Hixie> | your sample code didn't make sense to me |
| 08:07 | <Hixie> | closePath() doesn't do anything |
| 08:07 | <Hixie> | (other than add a line to the path) |
| 08:07 | <sicking> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext ? |
| 08:08 | <Hixie> | yes |
| 08:08 | <sicking> | Hixie: still not updated, second argument is a coordinate |
| 08:08 | <Hixie> | oh, right, that's the multipage copy. that won't update til i commit either, sorry. |
| 08:09 | <sicking> | Hixie: yeah, the code is bogus, i very rarely write canvas code so i forget how it works |
| 08:09 | <Hixie> | the other thing in your mail i didn't really understand is "drive user focus" |
| 08:09 | <Hixie> | i assume you mean drive the magnification |
| 08:09 | <sicking> | Hixie: yes |
| 08:09 | <Hixie> | ok |
| 08:09 | <Hixie> | i understand what you meant now |
| 08:10 | <Hixie> | i love that anyone thinks authors are going to be enabling text selection on their canvases |
| 08:10 | <Hixie> | it's so optimistic |
| 08:13 | <sicking> | Hixie: so can you give me a very short code example? |
| 08:13 | <Hixie> | to do what? |
| 08:13 | <sicking> | Hixie: assuming you have a 2dcontext already |
| 08:14 | <sicking> | Hixie: to draw a square focus rectangle |
| 08:14 | <sicking> | Hixie: assuming I don't feel the need for overriding OS style |
| 08:14 | <Hixie> | c.beginPath(); c.rect(x,y,w,h); c.drawFocusRect(widget); |
| 08:15 | <sicking> | no closePath? |
| 08:15 | <Hixie> | (will only draw it if |widget| is actually focused) |
| 08:15 | <Hixie> | rect() autocloses the path |
| 08:15 | <sicking> | cool |
| 08:16 | <sicking> | so what were the coordinates in the old (currently committed to w3c) syntax? |
| 08:16 | <Hixie> | they were the center of the caret |
| 08:16 | <sicking> | also, should that be "Ring" rather than "Rect"? |
| 08:16 | <Hixie> | (the idea was that whenever you moved the caret, you would redraw the ring and give the new caret coords) |
| 08:16 | <Hixie> | yes |
| 08:22 | <sicking> | Hixie: is removing the coordinates something that richard has requested? Or is otherwise part of the WG decision? |
| 08:23 | <Hixie> | yeah it's the main part of his request as far as i can tell |
| 08:23 | <Hixie> | the main problem with the old style is it required using a clipping region to avoid repainting the focus ring every time the caret moves |
| 08:23 | <Hixie> | and it doesn't give a way to show selections |
| 08:24 | <Hixie> | of course imho you shouldn't be using canvas at all for carets, so it's rather moot to me, and i'd be fine simply not supporting this use case at all |
| 08:24 | <Hixie> | (focus rings around buttons, etc, is fine, obviously) |
| 08:24 | <sicking> | yeah, focus rings make a lot of sense, carets not so much |
| 08:25 | <othermaciej> | both carets and selection do have non-editing uses |
| 08:25 | <othermaciej> | whether anyone will use canvas for such, I don't know |
| 08:25 | <othermaciej> | canvas does let you draw text, and on Mac OS X, non-selectable text makes people sad, since it is very common to make even static error message text in dialogs selectable |
| 08:26 | <Hixie> | there's tons of non-selectable text on Mac OS X |
| 08:26 | <Hixie> | title bars, menus, tooltips -- and that's just what's on my screen right now :_) |
| 08:27 | <othermaciej> | yes, things that are active (i.e. draggable or clickable) are generally not selectable |
| 08:28 | <Hixie> | axis labels in grapher (a typical case of what you'd put on canvas) aren't selectable |
| 08:29 | <Hixie> | i don't really know what a good example of something you'd put in canvas as text is that is selectable in its native equivalent |
| 08:29 | <Hixie> | anyway i should sleep |
| 08:29 | <Hixie> | nn |
| 08:29 | <othermaciej> | they are in Keynote |
| 08:30 | <othermaciej> | what program makes graphs and won't let you select the label text? |
| 08:40 | <jacobolus> | people should just use prorovis :) |
| 08:40 | <jacobolus> | er, protovis |
| 08:40 | <jacobolus> | trying to make the canvas include selections seems like overengineering |
| 08:40 | <jacobolus> | there are better solutions for selectable text in the browser |
| 09:14 | <jgraham> | othermaciej: It would be nice to get a clear answer on the list about whether the poll is per organization or per individual |
| 09:15 | <othermaciej> | jgraham: chairs discussed it in email and I didn't see anything clear enough that I felt I could make an unambiguous statement |
| 09:15 | <othermaciej> | note that from a mechanical POV, the poll is configured as per individual |
| 09:15 | <othermaciej> | (it is possible to make WBS to enable per-org) |
| 09:15 | <jgraham> | Yes, I noted that already |
| 09:16 | <jgraham> | Which will make it pretty confusing later if it is announced that it is per-organisation |
| 09:16 | <jgraham> | But the discussion on the topic so far was organization-focused |
| 09:19 | <othermaciej> | well |
| 09:19 | <othermaciej> | there is going to be an AC survey after this |
| 09:20 | <othermaciej> | at that point, the W3C AC Reps can express the official POV of their respective orgs |
| 09:20 | <othermaciej> | the goal of this survey is to get a sense of the WG |
| 09:22 | <othermaciej> | I think it's likely that the chairs will interpret it as per-individual, but I would say in any case, at this stage, there's nothing wrong with responding as an individual |
| 09:22 | <othermaciej> | and just noting if you intend to express views on behalf of an organization |
| 09:23 | <jgraham> | OK |
| 09:57 | <jgraham> | TabAtkins: Where did you get """The <body> element is supposed to be the "default article" for the page""" from? |
| 13:00 | <roc> | jgraham: perhaps Steve Faulkner is only objecting to including that text *as part of the canvas-accessibility change* |
| 13:15 | <jgraham> | roc: Perhaps. But then I don't understand why he doesn't say that. And why th process pedantry is needed |
| 13:16 | <roc> | yeah I'm being optimistic |
| 13:23 | hsivonen | is reading week-old public-html email, seeing alt discussion going around in the same old circles after Decisions |
| 13:42 | <zcorpan> | is FALLBACK:\noffline.html valid? or do you need to specify a fallback namespace? |
| 13:46 | <zcorpan> | seems you need the fallback namespace |
| 13:54 | hsivonen | reaches the thread where sicking says he can patch a browser to do X and Steve argues back that no browser does X. |
| 13:57 | <zcorpan> | lol |
| 14:05 | <hsivonen> | that discussion in rather prototypical of the communcation problem between browser developers and accessibility advocates :-( |
| 16:08 | <TabAtkins> | jgraham: From the fact that the <body> has the semantics of <article>. |
| 16:13 | <AryehGregor> | I have received five identical form e-mails in the last 24 hours from the Google Apps Team informing me that recent announced changes that I never heard of don't affect the various sites I have signed up to Google Apps, so I don't have to worry about them. This strikes me as inefficient. |
| 16:13 | <AryehGregor> | I wonder what happens to people who have thousands of sites on Google Apps. |
| 16:13 | <AryehGregor> | To be fair, the five e-mails were sent to five different addresses that all forward to me, so maybe they're only sending one per e-mail address. |
| 16:13 | <jcranmer> | don't worry, it's Google's attempts to challenge the CAN-SPAM act |
| 16:14 | <zcorpan> | Coming soon: Better spam in Gmail |
| 16:14 | <jcranmer> | I turned on one of the advertising things in Gmail just to laugh at it when it goes through my spam filter |
| 16:14 | <jcranmer> | er, folder |
| 16:46 | <bga_> | http://docs.codehaus.org/display/GROOVY/Groovy%2B1.8%2Brelease%2Bnotes#Groovy1.8releasenotes-CommandchainsfornicerDomainSpecificLanguages |
| 17:10 | <jgraham> | TabAtkins: ]citation needed] |
| 17:11 | <jgraham> | s/]/[/ |
| 17:12 | <MikeSmith> | hsivonen: just sent you an updated version of the alternative-text checking patch |
| 17:12 | <gsnedders> | jgraham: Mismatched brackets. |
| 17:12 | <MikeSmith> | hsivonen: which deals properly with the nested-figure case |
| 17:14 | <Philip`> | gsnedders: Not if you have a non-stupid regexp engine |
| 17:15 | <gsnedders> | Philip`: I don't have one of those. :'( |
| 17:17 | <espadrine> | Philip`: by the way, /a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?aaaaaaaaaaaaaaaaaaaaaaaa/.exec('aaaaaaaaaaaaaaaaaaaaaaa') takes forever to *run* in chrome and opera |
| 17:17 | <espadrine> | and fast in firefox |
| 17:18 | <espadrine> | which one is non-stupid? |
| 17:18 | gsnedders | wonders how that is fast in Firefox |
| 17:21 | <AryehGregor> | I get 0 ms for both Firefox and Opera, but 100+ ms for Chrome. |
| 17:21 | <AryehGregor> | How can that possibly take 100+ ms to evaluate? |
| 17:21 | <AryehGregor> | Oh, I guess it's trying to check all the possibilities and doesn't realize lots are the same . . . |
| 17:21 | <espadrine> | I think they detect this kind of regexp, or something |
| 17:21 | <AryehGregor> | 2^18? |
| 17:22 | <gsnedders> | AryehGregor: Backtracking. |
| 17:22 | <AryehGregor> | Does changing it to a?b?c?... make it slower? |
| 17:22 | <AryehGregor> | Oh, but that would mean you wouldn't have to backtrack, maybe? |
| 17:22 | AryehGregor | doesn't know how these things work, clearly |
| 17:23 | <AryehGregor> | Regex is like a CPU: I know how it works in a black-box sort of way, but the innards are pure magic. |
| 17:23 | <AryehGregor> | (okay, I understand the innards of regex and CPUs a little bit) |
| 17:23 | <gsnedders> | AryehGregor: a?a? you may just optimize to a{0,2}, so that's how you make that case quick |
| 17:24 | <gsnedders> | AryehGregor: but a?b?c? you can't, unless you transform the NFA you create to a DFA (and creating a DFA is potentionally O(n^2), and JS RegExp isn't actually entirely regular, so not all RegExp can be converted to DFA) |
| 17:25 | <Philip`> | Does /(a?)(a?)(a?).../ go slow in more browsers? |
| 17:25 | <AryehGregor> | But a?b?c?... wouldn't be slow with the given string, since none of the letters after the first occur, so you don't have to backtrack, right? |
| 17:25 | <gsnedders> | AryehGregor: So you have a trade-off between compiling to a DFA (O(n^2) worst-case) and then O(n) runtime, or 0 compiling time and worst-case O(x^n) runtime… |
| 17:25 | <gsnedders> | AryehGregor: No existing JS impl compiles to a DFA, though |
| 17:26 | <Philip`> | I think DFAs are O(2^n), not O(n^2) |
| 17:26 | <gsnedders> | Philip`: Entirely possible my memory is wrong :) |
| 17:26 | <espadrine> | hmm, yep, I think it is exponential complexity... |
| 17:27 | <AryehGregor> | Philip`, with (a?) it's just as fast in Firefox and Opera for me. |
| 17:27 | <gsnedders> | Yeah, wikipedia says Philip` is right |
| 17:28 | <espadrine> | AryehGregor: putting parenthesis is still slow in chrome |
| 17:29 | <AryehGregor> | espadrine, he was asking if that made it slower, not if it made it faster. |
| 17:29 | <AryehGregor> | I assume it will only ever make it slower. |
| 17:29 | Philip` | was just guessing it might defeat optimisations that detect that particular pattern |
| 17:29 | <espadrine> | ah, yes |
| 17:29 | <AryehGregor> | It should defeat simple tricks like replacing it with a{0,18} or such. |
| 17:29 | <AryehGregor> | Since you have to provide eighteen separate matches. |
| 17:30 | <AryehGregor> | (assuming I counted right, which is not a reliable assumption) |
| 17:30 | <Philip`> | (Maybe they cleverly detect that you're ignoring the return value of the regexp?) |
| 17:30 | <AryehGregor> | I wondered about that. |
| 17:32 | <gsnedders> | Philip`: That would be quite hard to do |
| 17:32 | <AryehGregor> | Philip`, also, the return value is null in this case. |
| 17:35 | <AryehGregor> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/967 |
| 17:35 | <AryehGregor> | Firefox and Opera are 0 ms in all four cases. |
| 17:35 | <AryehGregor> | Chrome gets me around 50 ms in the first two cases (no match), 5 ms in the last two (match). |
| 17:36 | AryehGregor | concludes V8 regex is just slow |
| 17:36 | <AryehGregor> | (at least in this case) |
| 17:38 | <gsnedders> | AryehGregor: We cache results for regexp, so that might help there |
| 17:38 | <AryehGregor> | That's probably why Chrome speeds up when I do more iterations. |
| 17:38 | <AryehGregor> | But the basic effect is still visible with a single iteration. |
| 17:38 | <gsnedders> | I know when Carakan shipped we were the only ones to cache results, dunno about now. |
| 17:41 | <AryehGregor> | Chrome is pretty clearly doing *something* to speed up repeated regexes. |
| 17:42 | <AryehGregor> | Not fully caching the result, that's clear, but the first call to the slow regex takes 100+ ms and subsequent calls take only 50 ms. |
| 17:43 | <AryehGregor> | Maybe it does some kind of time-consuming optimized compile of the regex, and caches the compiled version, or something. |
| 17:45 | <MikeSmith> | ah, wonderful - Joyent has trademarked "Node.js" and released a statement saying stuff like "Use of a trademark in a domain name (e.g., nodeconsultingservices.com)" is now prohibited |
| 17:47 | <AryehGregor> | nodeconsultingservices.com was just registered anonymously today. |
| 17:47 | <AryehGregor> | And redirects to http://www.dchest.org/node.html. |
| 17:47 | <MikeSmith> | heh |
| 17:47 | <MikeSmith> | beautiful |
| 18:33 | <AryehGregor> | Regex for e-mail addresses on eichlers.com: /^[\w\.-]{1,}\@([\da-zA-Z-]{1,}\.){1,}[\da-zA-Z-]{2,3}$/ |
| 18:33 | <AryehGregor> | So they assume that + isn't valid in addresses, and also that TLDs are either 2 or 3 characters long. |
| 18:34 | <AryehGregor> | This foils all my unique-addressing schemes. |
| 18:34 | <jcranmer> | can't do .uk then :-) |
| 18:34 | <AryehGregor> | Why not? |
| 18:34 | <jcranmer> | oh, 2 characters |
| 18:34 | <AryehGregor> | That looks like it will work. |
| 18:34 | <jcranmer> | can't do .info then |
| 18:34 | <AryehGregor> | Or .name. |
| 18:34 | <AryehGregor> | Like, you know, aryeh.name. |
| 18:34 | <jcranmer> | or .invalid |
| 18:34 | <AryehGregor> | . . . it's not really necessary to allow .invalid. |
| 18:34 | <AryehGregor> | But there's .museum. |
| 18:34 | <AryehGregor> | I could make aryehgregor.com a CNAME for aryeh.name. |
| 18:34 | <jcranmer> | |
| 18:35 | <AryehGregor> | Pretty sure that one's not registered yet. |
| 18:35 | <jcranmer> | it's almost surely coming |
| 18:35 | <AryehGregor> | Surely it's redundant, though. Isn't everything useful on the Internet already owned by Google? |
| 18:35 | <jcranmer> | .microsoft, or would the opt for .ms? or .m$? |
| 18:36 | <AryehGregor> | .m$ would be invalid. |
| 18:38 | <AryehGregor> | Why doesn't Gmail use minus-addressing instead of plus-addressing? A lot more sites accept minuses. |
| 18:38 | <AryehGregor> | Although I've seen one that didn't. |
| 18:40 | <jcranmer> | I've had my dad's email get rejected because it is @l-3.com or something similar |
| 18:43 | <webben> | I tend to caution against validating more than something like /^[^@]+@[^@]+$/ |
| 18:43 | <AryehGregor> | Mediawiki used to do /@/ or such. |
| 18:44 | <AryehGregor> | <input type=email> is a reasonable compromise, plus it's easy to use. |
| 18:44 | <AryehGregor> | If it were only properly implemented. |
| 18:44 | <webben> | It's not like you're going to catch all invalid email addresses (and valid email addresses that are typos are uncatcheable but just as likely) so the main effect of overvalidation is to annoy people, especially potential customers. |
| 18:44 | <AryehGregor> | MediaWiki is now a bit more demanding, IIRC, but not too narrow. |
| 18:44 | <AryehGregor> | <input type=email> does prohibit some technically valid addresses. |
| 18:45 | <webben> | I think it's okay for large codebases like MediaWiki or browsers to do it. |
| 18:45 | <webben> | ... on the perhaps over-optimistic idea they'll do it right. |
| 18:45 | <AryehGregor> | Like where the host part is a bracketed IP address instead of a domain. |
| 18:45 | <Ms2ger> | AryehGregor, how about adding "this site was optimized for Gecko 2+"? :) |
| 18:45 | <AryehGregor> | Ms2ger, as well as a JavaScript shim to disable it in WebKit and Presto? Sounds good to me. |
| 18:46 | <AryehGregor> | (I haven't checked if current WebKit has a horrifyingly broken <input type=email> implementation) |
| 18:46 | <Ms2ger> | (Me neither, but I assume so) |
| 18:46 | <AryehGregor> | Oh, it seems to actually have UI in Chrome 12 dev? |
| 18:46 | <AryehGregor> | Interesting. |
| 18:47 | <AryehGregor> | Doesn't seem too terrible at first glance. |
| 18:47 | <AryehGregor> | Doesn't alert you until submit, that's bad. |
| 18:47 | <AryehGregor> | Also doesn't flag invalid fields until submit. |
| 18:47 | <webben> | I use the FILTER_VALIDATE_EMAIL in PHP http://www.php.net/manual/en/filter.filters.validate.php ... mind you I tend to assume that's probably wrong. |
| 18:47 | <AryehGregor> | But it seems about on par with Opera, except less ugly. |
| 18:47 | <AryehGregor> | webben, one problem is the RFCs are wrong. |
| 18:47 | <AryehGregor> | They prohibit some addresses that are usable and used in practice. |
| 18:48 | <AryehGregor> | Like ones starting or ending in dots, or with multiple consecutive dots. |
| 18:48 | <AryehGregor> | They also probably allow some addresses that in practice are not going to be routable. |
| 18:48 | <webben> | orly? didn't realize they prohibited addresses in use. |
| 18:48 | <AryehGregor> | The RFCs do, yeah. |
| 18:48 | <AryehGregor> | See the note in HTML5. |
| 18:49 | <AryehGregor> | http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address |
| 18:49 | <AryehGregor> | "Note: This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, white space characters, and quoted strings in manners unfamiliar to most users) to be of practical use here." |
| 18:50 | <webben> | ah yes |
| 19:19 | <aho> | ah yea... had a scary thought yesterday. what if there were css media queries for... the subpixel ordering of the display |
| 19:19 | <aho> | :> |
| 19:20 | <aho> | (there is subpixel aware image resizing for example) |
| 19:54 | <Hixie> | some of the comments on http://www.w3.org/2002/09/wbs/40318/html5-license-poll-v3/results are unintentionally funny |
| 19:54 | <Hixie> | e.g. arguing that we should not have a forking spec because " A national governnment could create its own intentionally incompatible national version of the html specification in order to prevent general Web access from within that country." |
| 19:54 | <Hixie> | surely if a national government had the power to force everyone to use a particular web browser that implemented their spec, they would also have the power to ignore copyright? |
| 19:55 | <AryehGregor> | I find that almost any use-case involving malicious governments is ridiculous. |
| 19:57 | <webben> | There are plenty of malicious governments, but incompetence is more likely to bite people. |
| 19:57 | <webben> | Korea's dependence on activex for example |
| 19:58 | <Hixie> | i just lose the idea that the copyright we put on the spec would be more powerful than a national goverment |
| 19:58 | <webben> | But sure ... violating W3C's copyright seems somewhat down the list of government crimes against humanity in a typical totalitarian state... |
| 19:59 | <gsnedders> | Hixie: Doesn't the Berne convention prevent that? |
| 19:59 | <gsnedders> | Hixie: Assuming said goverment was a signee of it, ofc |
| 19:59 | <AryehGregor> | gsnedders, how do you enforce it? |
| 19:59 | <Hixie> | what AryehGregor said |
| 19:59 | <AryehGregor> | There's no international court with the authority to enforce the Berne convention. |
| 19:59 | <AryehGregor> | Countries that ratified it are just saying that they'll implement it in their local laws. |
| 20:00 | <gsnedders> | Indeed, it's a good point. |
| 20:00 | <Hixie> | even governments that have signed on to international thingies can just say they changed their mind |
| 20:00 | <AryehGregor> | In fact, in United States law, you explicitly cannot cite the Berne Convention directly. It's not self-enforcing. |
| 20:00 | <AryehGregor> | You have to cite the relevant law that may happen to implement it. |
| 20:00 | <Hixie> | i mean, if the US can go to war without UN authority, i'm pretty sure a country would have no problem breaking copyright |
| 20:00 | <AryehGregor> | What can happen is that other countries will gang up and menace you a bit if you're too lax on IP laws, or other laws that affect them, but that has limited teeth to it. |
| 20:01 | <Hixie> | i also love the implication that the spec will enforce particular implementations |
| 20:01 | <AryehGregor> | It's not going to do anything about isolated incidents, unless they're big enough to actually cause a diplomatic incident. |
| 20:01 | <Hixie> | the whole concept of the argument i quoted is just unrealistic |
| 20:01 | <AryehGregor> | Which they won't be. |
| 20:02 | <AryehGregor> | Because realistically, when dealing with evil governments, we have bigger fish to fry. |
| 20:02 | <AryehGregor> | We don't even try to pressure them much on imprisoning and torturing political dissidents. |
| 20:03 | <AryehGregor> | International intervention is typically limited to cases of mass slaughter of civilians, and even that's not assured. |
| 20:03 | <Hixie> | yeah |
| 20:03 | <Hixie> | pretty much |
| 20:03 | <Hixie> | that and the risk that oil delivery might be blocked |
| 20:04 | <gsnedders> | When the country doing the blocking doesn't have nukes |
| 20:04 | <AryehGregor> | Yeah, that part's tricky. |
| 20:04 | <AryehGregor> | Nukes do a lot to ensure peace. |
| 20:05 | <AryehGregor> | Realistically, anyone with oil is going to be selling as much as they can, though, so the thing that's most likely to block oil delivery is actually war . . . |
| 20:05 | <AryehGregor> | Or blockade. |
| 20:05 | <AryehGregor> | Unless we specifically exempt large quantities of oil from the blockade, like in Saddam's Iraq. |
| 20:06 | <Hixie> | they might be selling it for too much, or to the wrong people |
| 20:06 | <AryehGregor> | Anyway, forking specs doesn't factor into it. |
| 20:06 | <Hixie> | or the oil company selling it might be the "wrong" company |
| 20:06 | <gsnedders> | AryehGregor: Russia cut off supply to Ukraine a while back, through which a lot of oil in Europe runs from |
| 20:06 | <Hixie> | it's not like a government would even fork the spec to do that case |
| 20:06 | <Hixie> | they'd make a new browser without a spec |
| 20:06 | <AryehGregor> | They sell it for market price, to whoever will pay the most, and if they don't sell to whoever pays the most then the buyer will just resell it at a higher price. Oil is very fungible. |
| 20:07 | <AryehGregor> | Trying to control who buys it is kind of silly. Like laws requiring Alaska to sell oil to the US instead of Russia, even though Russia is much closer and it would make more sense to sell to Russia and use the money to buy more oil from elsewhere. |
| 20:07 | <Hixie> | i mean seriously, what are the odds that a government would be pro-competition (need a spec to get interoperable implementations), but anti-competition (implementations not allowed to implement the other spec) at the same time? |
| 20:07 | <AryehGregor> | Oh well. Economics. |
| 20:10 | <Ms2ger> | Hixie, why does the WHATWG approve of such governments by having a sane license? :) |
| 20:12 | <Hixie> | Ms2ger: i suppose it's because we want the web to fall apart |
| 20:12 | <Hixie> | Ms2ger: so that flash and .net can take over |
| 20:14 | <mpilgrim> | wtf did i just walk into? |
| 20:14 | mpilgrim | reads logs |
| 20:14 | <AryehGregor> | Wow, the survey results so far are staggeringly lopsided toward the free licenses. |
| 20:14 | <mpilgrim> | oh, licensing |
| 20:17 | <mpilgrim> | wow |
| 20:17 | <mpilgrim> | "W3C is the best place to develop html specs. It is an open and fair standards org. We do not want others to fork W3C specs." |
| 20:17 | <Hixie> | TabAtkins: it would be convenient if you could give the "In the absence of more specific rules" algorithm in http://dev.w3.org/csswg/css3-images/ a more distinctive name that i could reference directly |
| 20:18 | <mpilgrim> | none of those 3 sentences are true |
| 20:18 | <Hixie> | mpilgrim: well the last sentence is presumably true |
| 20:18 | <Hixie> | mpilgrim: for their definition of "we" |
| 20:18 | <Hixie> | mpilgrim: and the first might be true, given a particular definition of "best" that prioritises differently than we do |
| 20:19 | <mpilgrim> | well, they're all opinion statements, so i should clarify: i disagree vehemently with each of those 3 sentences. |
| 20:19 | <Hixie> | mpilgrim: the bigger problem is that even if you grant all three premises, it still doesn't mean a non-forking license |
| 20:19 | <Hixie> | mpilgrim: on the contrary, it increases the power of a free licenses |
| 20:20 | <Hixie> | s/s$// |
| 20:20 | <mpilgrim> | wow, those results really are lopsided |
| 20:20 | <Hixie> | mpilgrim: as if the w3c is the best place to develop specs, then nobody will want to fork |
| 20:20 | <Hixie> | mpilgrim: and if people _can_ fork, the w3c is motiviated to _remain_ the best place |
| 20:20 | <Hixie> | mpilgrim: and to _remain_ open and fair |
| 20:21 | <Hixie> | mpilgrim: so imho someone with that opinion should want a free license |
| 20:21 | Hixie | stops preaching to the choir |
| 20:22 | <mpilgrim> | thanks, my neck was beginning to hurt from all the aggressive nodding i was doing |
| 20:22 | <mpilgrim> | oh well, back to actually improving the web |
| 20:22 | <mpilgrim> | i'm contributing to webkit now |
| 20:23 | <Hixie> | nice |
| 20:23 | <mpilgrim> | webkit's indexeddb implementation is less buggy than it was last week |
| 20:23 | <TabAtkins> | Hixie: Yes, I was thinking I should. I'll do so in a bit. |
| 20:23 | <Hixie> | TabAtkins: i'm using the section title for now, let me know if i should change that |
| 20:24 | <Hixie> | TabAtkins: though actually, i'm thinking maybe i should just copy the part i need into html. i'm only actually using the very last two bullet points of the algorithm. |
| 20:24 | <Hixie> | (context is http://www.w3.org/Bugs/Public/show_bug.cgi?id=11488 btw) |
| 20:25 | <TabAtkins> | Yeah, thought so. |
| 20:26 | <TabAtkins> | Those points definitely aren't going to change, so if you just want to copy them, go for it. Or, copy the sizing algorithm for list-style-image in 2.1, which is a simpler version. |
| 20:26 | <Hixie> | well i went for reference for now |
| 20:26 | <Hixie> | regenning so you can see it, one moment |
| 20:28 | <Hixie> | TabAtkins: first paragraph after the green box in http://www.whatwg.org/specs/web-apps/current-work/complete.html#images |
| 20:28 | <Hixie> | if you have a stable ID in that spec I can link straigth to it |
| 20:29 | <TabAtkins> | http://dev.w3.org/csswg/css3-images/#default-sizing |
| 20:29 | <Hixie> | roger |
| 20:33 | <mven> | anybody know if any browsers supports the video stream api yet? Been trying to look online for the past day. Came up nil |
| 20:36 | <Hixie> | opera nightlies have something iirc |
| 20:36 | <Hixie> | lachy knows about it, if he comes back |
| 20:37 | <gsnedders> | Pretty much just the old device element, AFAIK |
| 20:37 | <gsnedders> | But I don't really know much what goes on outside of ecmascript nowadays |
| 20:37 | <mven> | Hixie: great, thanks. |
| 21:54 | <zcorpan> | i wonder why people claim Hixie isn't following the process when there's a change they disagree with |
| 21:55 | <TabAtkins> | I'm guessing you want to hear something other than "They're dishonest and incapable of understanding that they may be wrong."? |
| 21:59 | <TabAtkins> | I suppose I should be fair. It could be malice *or* incompetence. |
| 22:02 | <zcorpan> | hmm, maybe a better approach with <form action=""> is for validators to issue a warning when there's a <base> and they see either <form> or <form action=""> |
| 22:11 | <Hixie> | othermaciej: so does rich's answer mean i can apply the patch? |
| 22:14 | <othermaciej> | Hixie: thanks for updating the patch - since Faulkner also objected to an earlier version, I think it would be good to give him a chance to reply too - I'll ask him on-list |
| 22:14 | <Hixie> | k, let me know when i can check it in |
| 22:15 | <othermaciej> | will do |
| 22:16 | <jgraham> | He could have been answering "yes" to "can you review" |
| 22:17 | <Hixie> | that's why i asked maciej and didn't just assume one way or the other... |
| 22:19 | <jgraham> | zcorpan: I think the essential point is that when you are arguing about process you have already lost |
| 22:21 | <TabAtkins> | Pound on the facts, pound on the law, or pound on the table? |
| 22:22 | <TabAtkins> | I'm guessing this translates over to "pound on research, pound on design, or pound on process". |
| 22:25 | <Hixie> | wow there's nothing quite like the kind of annoyance that testing onbeforeunload involves |
| 22:25 | <Hixie> | it's not a lot of annoyance, just a special kind |
| 22:25 | <TabAtkins> | Because the feature is intrinsically annoying, or it's just confusing and inconsistent? |
| 22:25 | <TabAtkins> | Or you have to close a window to test it? |
| 22:25 | <Hixie> | neither, that's why it's a special kind |
| 22:25 | <Hixie> | every time you reload the page to test it, you get the prompt that you're testing |
| 22:26 | <Hixie> | but is it the new prompt or the old prompt? |
| 22:26 | <Hixie> | and you made the prompt say not to ok the prompt but should you ok it because it's not part of the test now or not because it is gah |
| 22:26 | <TabAtkins> | The old one. Hitting Refresh exercises the prompt for the current page, presumably? |
| 22:26 | <Hixie> | yeah i mean it's always understandable, but it keeps trying to confuse you |
| 22:26 | <TabAtkins> | Gotcha. |
| 22:27 | <Hixie> | and then when you're done you close the browser and BOOM, prompt again |
| 22:31 | <zcorpan> | javascript:(function(){onbeforeunload=null})() |
| 22:34 | <zcorpan> | mven: http://my.opera.com/core/blog/2011/03/23/webcam-orientation-preview |
| 22:47 | <sicking> | Hixie: i bet you can write an extension that adds a 'reload-without-unload-prompt' button :) |
| 22:47 | <Hixie> | i have bigger fish to fry :-) |
| 22:48 | <zewt> | writing an extension that modifies what you're testing is also a fantastic testing methodology :) |
| 22:51 | <Hixie> | yeah that does seem to be asking for trouble |
| 22:53 | <zcorpan> | i'd be satisfied with the STFU bookmarklet above :) |
| 22:53 | <zcorpan> | unless you're testing iframes and stuff |
| 22:54 | <zcorpan> | which i guess would be a good thing to test |
| 22:54 | <sicking> | fortunately that wasn't what i proposed :) |
| 22:54 | <sicking> | it'd only modify the page you're no longer testing |
| 22:54 | <sicking> | but it's still probably more work than it's worth |
| 23:39 | <AryehGregor> | Okay, so my first draft at a response to the licensing survey is about 1500 words. I'll have to take some time to cut it down a bit. |
| 23:39 | <AryehGregor> | (it seems no one gave a thorough response yet) |
| 23:42 | <mven> | zcorpan: thanks. much obliged |
| 23:42 | <Hixie> | AryehGregor: are you going to mention the things that were discussed in #whatwg earlier? |