| 00:56 | <TabAtkins_> | Any of the html5lib guys awake at the moment? |
| 00:59 | <Philip`> | Depends on who is sufficiently an html5lib guy for your requirements |
| 01:01 | <TabAtkins_> | Anyone responsible for the development of it. |
| 01:03 | <Philip`> | I have commit access and wrote some bits of its code |
| 01:03 | <Philip`> | though I'm largely irresponsible |
| 01:04 | <TabAtkins_> | Good enough. You have any clue if you guys are going to try and get it pushed into the standard modules? |
| 01:05 | <Philip`> | I don't believe I've heard anybody intending to try that any time soon |
| 01:05 | <TabAtkins_> | Kk. |
| 01:05 | <Philip`> | It ought to be made fast (i.e. written in C) before attempting to make it standard |
| 01:06 | <TabAtkins_> | The teacher in this Python class I'm taking was just wondering. |
| 01:07 | <TabAtkins_> | As he had it listed as a standard external module. |
| 02:18 | <TabAtkins> | annevk: A Python class. |
| 04:47 | <paul_irish> | boblet: i'm working on your feature request. :) |
| 04:47 | <boblet> | paul_irish: lol |
| 04:47 | <boblet> | sorry to forget the @ in the original |
| 04:48 | <boblet> | I was pretty shocked how much things have changed in the last two years |
| 04:48 | <boblet> | really didn’t realise the rate of progress |
| 04:48 | <boblet> | yay browser makers! |
| 04:50 | <asmodai> | hsivonen: Oh very colol indeed. |
| 04:50 | <asmodai> | cool |
| 04:50 | <paul_irish> | totally. :) now, would you expect ie7 to remain in the same position as you change years? |
| 04:50 | <asmodai> | http://validator.nu/?doc=http%3A%2F%2Fwww.in-nomine.org%2F~asmodai%2F3d.html passes as expected |
| 04:50 | <asmodai> | \o/ |
| 04:51 | <asmodai> | Now to go back to being drained of my bodily moisture in this Thai heatwave |
| 04:52 | <boblet> | paul_irish: yeah — each browser is in the same arc, so flipping between 2008, 2009 and 2010 shows each arc filling out (well, depending on browser) |
| 04:52 | <divya> | boblet: some browsers disappear in later years |
| 04:53 | <paul_irish> | yah only from 2008, only ie7 survives until the 2010 view. :/ |
| 04:53 | <boblet> | that makes things a little tricky |
| 04:53 | <divya> | Firefox 2 survives 08/09 |
| 04:55 | <divya> | we could probably assign a position for each browser (irrespective of version) |
| 04:55 | <boblet> | hrm, you could have arcs for every browser in all views, and have them blank when that browser isn’t represented |
| 04:55 | <boblet> | divya: yeah |
| 04:56 | <boblet> | that’d work too |
| 04:56 | <divya> | so 3 spaces for IE 2 spaces for FF and 1 each for the rest. |
| 04:57 | <paul_irish> | and a ghost ie5 |
| 04:57 | <boblet> | :| |
| 04:58 | <divya> | paul_irish: whaaaa |
| 04:58 | <divya> | In any case I think this should be an 'alternate view' but not default :| |
| 05:01 | <boblet> | divya: completely agree. current view is more helpful. ‘locked’ view only good for over-time comparison |
| 05:02 | <boblet> | btw you can use numbers in class names if you want ;-) (twenty10 etc is cute tho!) |
| 05:03 | <boblet> | s/use numbers in class names/start class names with numbers/ |
| 05:03 | <boblet> | (read what I thought, not what I typed) |
| 05:03 | <boblet> | ;-) |
| 05:04 | <paul_irish> | you can? whoa sweet |
| 05:05 | <boblet> | paul_irish: in HTML5 class/id names can be any unicode character(s) except space |
| 05:05 | <boblet> | kanji is fine |
| 05:05 | <paul_irish> | beautiful. |
| 05:05 | <paul_irish> | does that degrade fine? |
| 05:06 | <boblet> | dunno about browser support for crazy things like smileys, but a starting number was only ever a validation issue, and I’ve seen kanji class names over here on live Japanese sites |
| 05:06 | <divya> | boblet: woah sweet! |
| 05:07 | <boblet> | :) |
| 05:07 | <divya> | last time I tried, it didnt detect for ids starting with numbers. Though that was more than a year ago :/ |
| 05:08 | <boblet> | http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#classes which links to http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#space-separated-tokens |
| 05:08 | <boblet> | “A set of space-separated tokens is a string containing zero or more words separated by one or more space characters, where words consist of any string of one or more characters, none of which are space characters” |
| 05:09 | <boblet> | divya: it meaning validator? |
| 05:10 | <divya> | boblet: no, the styles did not apply :/ |
| 05:10 | <divya> | when I did #1 { blah: blah; } |
| 05:10 | <boblet> | ohrly!? do you remember which browser? |
| 05:10 | <divya> | boblet: wow most likely Firefox but that was a long time ago :/ |
| 05:11 | <boblet> | crikey, didn’t think browsers would actually enforce that rule. seems pretty brutal |
| 05:12 | <boblet> | well, maybe I’m living in a theoretical world then re: starting with a number |
| 05:12 | <divya> | boblet: they still dont http://dl.dropbox.com/u/952/random.html |
| 05:13 | <boblet> | yeah, I’m finding the same thing ;-( |
| 05:13 | <boblet> | jeez, that’s crap |
| 05:15 | <divya> | could it be something to do with DOM naming prefs |
| 05:15 | <boblet> | sorry for ray of false hope |
| 05:15 | <divya> | ROFL |
| 05:17 | <paul_irish> | boblet: its up. take a look |
| 05:19 | <boblet> | ooo nice jeorb! :) |
| 05:21 | <boblet> | btw I tested class and id names with →, ☺ and オ. all worked |
| 05:22 | <boblet> | so there’s something about starting numbers huh |
| 05:22 | <boblet> | (all worked = latest Chrome, Webkit, Opera, Firefox) |
| 05:25 | <divya> | boblet: ha! That is interesting to note :) I sense a blog post :P |
| 05:25 | <boblet> | divya: I’ll leave the IE checking to you ;-) |
| 05:28 | <divya> | boblet: sheesh The only Windows I have is Vista which eats my battery in 2 mins flat. |
| 05:30 | <boblet> | that’s a short window for browser testing |
| 05:31 | <boblet> | paul_irish: the JS var twenty10 etc in script.js are how you’re doing the alternate view right? |
| 05:32 | <paul_irish> | yup |
| 05:33 | <paul_irish> | it looks to see if there isnt a block where it expects one and chucks in a fake one |
| 05:33 | <paul_irish> | going one by one through the browsers through the yeras. |
| 05:34 | <boblet> | huh. tried to hack a version with all browsers taking a slot on every year, but the script doesn’t seem to work on the locally saved version. maybe b/c Chrome saved the HTML with all-caps tags |
| 05:37 | <boblet> | yeah, that was it. wow, I done gone broke it good now tho |
| 05:38 | <paul_irish> | while you're at it, size the bars to be representative of browser market share, why dontcha. :) |
| 05:39 | <boblet> | sure, right after I pop round to bring you both a cup of tea and a biscuit… |
| 05:39 | <divya> | boblet: Earl Grey Pls. :) |
| 05:41 | <boblet> | divya: certainly ma’am, although perhaps ma’am would care to try the broken orange pekoe afternoon blend? |
| 05:42 | <divya> | boblet: only if it comes with a scone :P |
| 05:45 | <boblet> | I’ll just grab some clotted cream, brb |
| 06:06 | <annevk> | oh fun, more CORS email |
| 06:07 | <annevk> | yawn |
| 06:18 | <annevk> | webr3, please raise an issue only once instead of spamming it in every thread |
| 06:18 | <Hixie> | what's the best practice method of constructing an array of sorted strings when you receive them in a random order? |
| 06:19 | <Hixie> | collect them out of order then quick sort then remove duplicates? |
| 06:19 | <annevk> | webr3, also, it may help to read the archives, the issue you have been raising in about three emails since I was asleep has already been recorded and a solution has already been proposed |
| 06:19 | <Hixie> | that seems like it'd be slow |
| 06:20 | <annevk> | Hixie, spec doesn't have to be fast :p |
| 06:20 | <annevk> | assuming this is for WebSRT |
| 06:20 | <Hixie> | i'm writing code for my game |
| 06:22 | <annevk> | ooh, sounded very much like collecting cues and sorting them :) |
| 06:22 | <Hixie> | nah |
| 06:22 | <annevk> | I guess duplicates should've alarmed me |
| 06:22 | <Hixie> | hm, maybe it's better to just put them in an array doing mem moves as i go |
| 06:23 | <Hixie> | so they're pre-sorted |
| 06:23 | <Hixie> | but that seems like it'd involve a lot of moves... |
| 06:49 | <webr3> | annevk: point taken and I'll check through the archives to see if i can find it |
| 06:51 | webr3 | really doesn't want to be sending the mail(s) about CORS or having any worries or issues with it at all :( |
| 06:56 | <webr3> | Hixie: transfer them into an array as key's on the way in (rather than values), that'll remove all duplicates without any work |
| 06:57 | <Hixie> | "as key's"? |
| 06:57 | <webr3> | "string1" = '', |
| 06:57 | <webr3> | yeah instead of [] = "string1" |
| 06:57 | <webr3> | (depending on length of strings) |
| 06:58 | <Hixie> | oh i'm not using javascript |
| 06:58 | <Hixie> | this is a compiler language |
| 07:00 | <webr3> | non-option then i guess :) |
| 07:00 | <Hixie> | also i'm more concerned about the work the computer does than the work i have to do :-) |
| 07:04 | <webr3> | probably produce way less op codes, but depending on size of strings etc would have other performance hits |
| 07:04 | <webr3> | best of luck though, sure you'll figure it out easily enough (if not already) |
| 07:46 | <annevk> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=9662 -- lol |
| 07:47 | <annevk> | it's unfortunate that with the current process that bug may end up escalating to a meaningless vote |
| 07:47 | <annevk> | wasting everyone's time for something that will not change |
| 07:48 | <Hixie> | at least that's a technical question |
| 07:48 | <Hixie> | not as much of a waste of time as what reference to use for ascii |
| 07:50 | <annevk> | unlike this one, that one we could actually do something about |
| 07:50 | <annevk> | I wonder why Unicode doesn't define ASCII as code points 1-127 |
| 07:50 | <annevk> | 0-127 I mean |
| 07:52 | <annevk> | 44 new CORS emails since Tuesday in only one of the running threads |
| 07:52 | <othermaciej> | doesn't seem useful to change it |
| 07:52 | <annevk> | (not counting all the duplicates I receive) |
| 07:53 | <annevk> | also, nothing new (the claim about new is not accurate, it's simply not done) |
| 07:54 | <annevk> | and to be honest I'm not really sure what to say in the security section |
| 07:55 | <othermaciej> | annevk: if I had time I would volunteer to write a draft of a security section |
| 07:55 | <annevk> | I suppose I could expand the sentence on validation saying you shouldn't just pass on everything from origin a to c via yourself, b |
| 07:55 | <annevk> | but in the end developers won't read CORS |
| 07:57 | <webr3> | annevk: if it helps, I think they will |
| 07:58 | webr3 | is a developer, /me read it |
| 08:00 | <annevk> | sure a couple might |
| 08:00 | <annevk> | s/might/will/ |
| 08:00 | <annevk> | but most won't |
| 08:00 | <othermaciej> | annevk: I think security considerations should cover the following things: |
| 08:00 | <othermaciej> | 1) Two-party interactions |
| 08:00 | <othermaciej> | 2) Three-party interactions - potential for Confused Deputy risk in this scenario |
| 08:01 | <othermaciej> | 3) Ways to avoid Confused Deputy - validate inputs before retransmitting, distinguish requests made on behalf of third parties in your protocol, or use secret tokens in combination with CORS for services to be used cooperatively |
| 08:02 | <othermaciej> | 4) How you can use CORS combined with secret tokens to get a stronger defense than either separately, even for two-party interactions |
| 08:03 | <othermaciej> | I guess security considerations should also discuss the no-credentials mode of CORS, since that is in the CORS spec |
| 08:03 | <othermaciej> | and I guess there should be a list of potential pitfalls for implementors to watch out for, I think |
| 08:03 | <annevk> | there's http://dev.w3.org/2006/waf/access-control/#user-agent-security |
| 08:04 | <othermaciej> | that seems to be a good start on the UA issues |
| 08:04 | <othermaciej> | I could write at least a rough outline for the 4 things I mentioned |
| 08:05 | <othermaciej> | not sure I have time to draft final text |
| 08:05 | <annevk> | a draft might be enough for me to finish it |
| 08:06 | <annevk> | the outline sounds good, i'm just not sure how to fill them in... :/ |
| 08:11 | <webr3> | annevk: (i hate to ask, honestly) - if the headers (i mean the allowed headers) from UMP where added to CORS and it was sealed at that, would the vendors be happy / could it go through to rec. (security section aside) - hixie replied "I'm not familiar with the browser vendor opinions on this specific issue." - perhaps you know, or could ask /end - i swear I'll never mention CORS again |
| 08:12 | <webr3> | mhausenblas: morning :) |
| 08:13 | <Hixie> | i'd like to provide some text for xhr's intro section that talks about how to safely do some common things that tyler thinks are dangerous, but i haven't been able to figure out what that is exactly |
| 08:13 | <mhausenblas> | morning webr3 |
| 08:13 | <annevk> | webr3, I don't understand |
| 08:15 | <webr3> | annevk: CORS limits to 5 headers, UMP allows more headers (Location etc) still a whitelist, but also allows Uniform-Headers = "Uniform-Headers" ":" 1#field-name - basically http://dev.w3.org/2006/waf/UMP/#response-header-filtering section 4.2 only - could that be added to CORS [/me would be happy could work with that, under current setup i/we simply can't) |
| 08:15 | <webr3> | s/5/6 |
| 08:17 | <annevk> | I thought I already told you it's an open issue |
| 08:17 | <annevk> | And you already raised it more than once on the mailing list |
| 08:18 | <annevk> | patience |
| 08:18 | <webr3> | okay I'll take you at your word it's being handled & leave it there |
| 08:19 | <othermaciej> | CORS has a way to allow additional request headers |
| 08:19 | <othermaciej> | does it not have a way to expose additional response headers yet? |
| 08:19 | <annevk> | not yet, I'm waiting for whether we want to rename the headers or not |
| 08:19 | <annevk> | so far nobody replied so I guess we won't |
| 08:20 | <annevk> | (and by nobody I mean affected browser vendors) |
| 08:20 | <othermaciej> | what kind of replies are you looking for? |
| 08:20 | <othermaciej> | I'd rather not change them unless the new names are a huge improvement |
| 08:20 | <othermaciej> | I won't object if other vendors want to change |
| 08:21 | <othermaciej> | (we could always support the old names too for a transition period) |
| 08:21 | <annevk> | something like 1) looks great lets do it 2) if you change that proposed syntax to this lets do it 3) not worth the change 4) looks great, but only if Mozilla/WebKit makes the changes too |
| 08:22 | <annevk> | something like that |
| 08:22 | <annevk> | see http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/thread.html#msg508 othermaciej |
| 08:22 | <annevk> | oops http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0508.html (there's no thread) |
| 08:23 | <othermaciej> | oh, I see |
| 08:24 | <othermaciej> | does that cover all the headers that start with "Accesss-Cotrol-"? |
| 08:24 | <annevk> | yup |
| 08:24 | <annevk> | only "Origin" remains unchanged, effectively |
| 08:25 | <othermaciej> | "CORS" seems a bit mysterious as a header name, but I do like getting rid of the obsolete Access-Control |
| 08:27 | <annevk> | I couldn't really think of something better |
| 08:27 | <annevk> | "http cors" or some such would be easy to find though |
| 08:28 | <othermaciej> | I'm writing up my thoughts in email |
| 08:28 | <othermaciej> | my ideas so far: |
| 08:28 | <othermaciej> | CORS ==> Allow-Access |
| 08:28 | <othermaciej> | CORS-Methods ==> Allow-Methods |
| 08:28 | <othermaciej> | CORS-Headers ==> Allow-Headers |
| 08:29 | <othermaciej> | can't think of a good name for CORS-preflight |
| 08:29 | <othermaciej> | maybe Allow-Request-Headers to make space for the response version |
| 08:29 | <othermaciej> | or perhaps that one could be Reveal-Headers |
| 08:30 | <annevk> | Expose-Headers was my idea |
| 08:30 | <annevk> | CORS-Expose-Headers |
| 08:30 | <othermaciej> | I like Expose better than Reveal |
| 08:30 | <webr3> | annevk: perfect, anything like that |
| 08:30 | <annevk> | Allow-Access is not really accurate though, it's not really about granting access |
| 08:31 | <othermaciej> | isn't it? |
| 08:31 | <othermaciej> | that header is what the browser uses to determine whether to expose the response, right? |
| 08:31 | <othermaciej> | maybe it should be Expose-Response |
| 08:31 | <annevk> | that's an interesting one |
| 08:31 | <othermaciej> | unless it's also used for other purposes |
| 08:32 | <hsivonen> | can't we stop renaming things and let the platform stablilize? |
| 08:32 | <othermaciej> | I don't really want to rename things |
| 08:32 | <othermaciej> | the Access-Control-* names are not so great, but not so terrible I feel compelled to change |
| 08:33 | <othermaciej> | but others did raise the idea of change, so I'd like to propose good names in case we choose to do it |
| 08:34 | <othermaciej> | annevk: maybe (in this hypothetical renamed world) it should be Expose-Response in response to an actual request, and Allow-Access in response to a preflight |
| 08:35 | <annevk> | maybe Allow-Request? |
| 08:35 | <othermaciej> | for the preflight response that makes sense |
| 08:36 | <annevk> | and Preflight-For or some such instead of CORS-preflight |
| 08:36 | <othermaciej> | I'm not sure that makes things more clear |
| 08:37 | <annevk> | yeah |
| 08:38 | <annevk> | hsivonen, this part of the platform is not stable |
| 08:39 | <hsivonen> | annevk: self-fulfilling statement |
| 08:39 | <annevk> | hsivonen, but I'm not that keen on it either but since mnot argued quite strongly that the header names were too long and all I thought I should at least give it a chance |
| 08:39 | <annevk> | hsivonen, guess I'm mostly where othermaciej is with this |
| 08:39 | <webr3> | maybe mnot was challenge you to get as short as his "link" header |
| 08:40 | webr3 | chuckles |
| 08:40 | <annevk> | dunno, but "his" link header is around since HTTP 1.0 |
| 08:40 | <webr3> | ... k |
| 08:43 | <webr3> | fwiw.. i kinda like the "new header to expose more response headers ==> Expose-Headers (or Expose-Response-Headers)" idea :) |
| 08:43 | webr3 | runs |
| 08:46 | <annevk> | my google Buzz stream is nothing but my twitter/Flickr account and the twitter account of Sjoerd Visscher |
| 08:47 | <annevk> | I guess Buzz has failed; at least in my universe |
| 08:51 | <hsivonen> | people think of google-branded services as trustworthy private space. when google-branded services behave like facebook, it feels creepy |
| 08:51 | <Hixie> | google search is a private space? |
| 08:51 | <Hixie> | :-) |
| 08:52 | <hsivonen> | Hixie: people think their search terms are |
| 08:52 | <Hixie> | ah, fair enough |
| 08:53 | <othermaciej> | facebook doesn't tend to broadcast your info though |
| 08:53 | <othermaciej> | the buzz privacy debacle was totally different from the facebook privacy debacle |
| 08:54 | <annevk> | facebook exposes more and more |
| 08:54 | <othermaciej> | some private info was broadcast to the general public (perhaps partly by accident) as opposed to facebook which is giving your private data to business partners or people you don't know, in contravention of the expectations it set originally |
| 08:54 | <othermaciej> | I guess both cases come down to violating previously established expectations |
| 08:55 | <Hixie> | buzz was fixed pretty damn quick though |
| 08:55 | <hsivonen> | othermaciej: both debacles arise from similar actions but people thought google wouldn't do such a thing |
| 08:55 | <Hixie> | facebook's on the other hand seems to be intentional |
| 08:55 | <Hixie> | not that i'm trying to defend google |
| 08:55 | <hsivonen> | othermaciej: where as facebook has... let's say a different reputation |
| 08:56 | <othermaciej> | google did do a better job of reacting to the outcry |
| 08:56 | <hsivonen> | Hixie: I thought the buzz thing was an intentional greed-driven attempt to compete with facebook in their game |
| 08:57 | <othermaciej> | I've always assumed that Google only cares about my privacy to the extent it helps foster their self-image as doing no evil |
| 08:57 | <othermaciej> | hsivonen: buzz in general as a feature - yes |
| 08:57 | <annevk> | isn't buzz competing with twitter? |
| 08:57 | Hixie | decides to let his PR department handle the issue, since this is logged |
| 08:58 | <othermaciej> | buzz being shoved in, in a way that exposed personal information, that may have been intentional but it didn't seem very clearly thought out |
| 08:59 | <hsivonen> | annevk: twitter is pretty clear about what's public and what's private--unlike facebook |
| 09:09 | <annevk> | Hixie, the date on the January 1 2006 archive copy is a copypasta error: http://www.whatwg.org/specs/ |
| 09:09 | <Hixie> | fixed thanks |
| 10:12 | <MikeSmith> | hsivonen: I don't know if you saw my discussion with Ville on the validator mailing list, but people have been reporting unexpected EOF errors when using it |
| 10:12 | <MikeSmith> | I remember now I mentioned this to you earlier |
| 10:13 | <MikeSmith> | I don't get any errors if I post (using curl) from the shell to localhost port 8888 |
| 10:13 | <MikeSmith> | but in browsing through the log output for the instance, I do see EOF errors being logged |
| 10:14 | <MikeSmith> | with the root cause being this: |
| 10:14 | <MikeSmith> | Caused by: java.net.SocketException: Broken pipe |
| 10:14 | <MikeSmith> | at java.net.SocketOutputStream.socketWrite0(Native Method) |
| 10:14 | <MikeSmith> | at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) |
| 10:14 | <MikeSmith> | at java.net.SocketOutputStream.write(SocketOutputStream.java:136) |
| 10:14 | <MikeSmith> | at org.mortbay.io.ByteArrayBuffer.writeTo(ByteArrayBuffer.java:177) |
| 10:14 | <MikeSmith> | at org.mortbay.io.bio.StreamEndPoint.flush(StreamEndPoint.java:122) |
| 10:14 | <MikeSmith> | at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:693) |
| 10:14 | <MikeSmith> | ... 35 more |
| 10:15 | <MikeSmith> | well, if not the root cause, at least the lowest-level error that's causing the EOF |
| 10:17 | <MikeSmith> | hsivonen: see http://pastebin.org/229072 for the full record of the error |
| 10:18 | <MikeSmith> | I suspect this is just due to excessive load on the validator hosts, and that causing a timeout or something |
| 10:25 | <Philip`> | Hixie: Store the incoming strings in a hashmap (which will remove duplicates, total cost O(n) in the total number of strings), then extract and sort all the keys at the end (O(n log n) in the number of unique strings) - I can't imagine any way to be asymptotically faster than that |
| 10:27 | <othermaciej> | what was the problem? |
| 10:28 | <Philip`> | http://krijnhoetmer.nl/irc-logs/whatwg/20100513#l-177 |
| 10:29 | <othermaciej> | oh I see |
| 10:29 | <othermaciej> | yeah, that would be the best way |
| 10:30 | <othermaciej> | unique in O(N) with O(N) space, sort in O(N log N) |
| 10:31 | <othermaciej> | there's no way to beat N log N by putting things in the right place, because any data structure that sorts on insertion would take O(N log N) time to build |
| 11:14 | <MikeSmith> | hsivonen: validator.w3.org updated to latest upstream v.nu (SVG and MathML in text/html) |
| 11:15 | <MikeSmith> | also updated http://www.w3.org/html/check (but that is running my workspace code) |
| 11:44 | annevk | is even less of a fan of this hybi experiment now |
| 11:54 | <Dashiva> | annevk: What is it that's being overengineered this time? |
| 11:58 | <annevk> | Dashiva, process :) |
| 12:01 | <Dashiva> | Oh boy |
| 12:01 | <Dashiva> | Because it wasn't slow enough already? |
| 12:02 | <annevk> | more layers is better |
| 12:04 | <Dashiva> | Is there a requirements specification for how to decide on a proper definition of 'better'? |
| 12:05 | <annevk> | drafting one as we speak |
| 12:05 | <annevk> | though getting consensus on it might implode the WG |
| 12:05 | <annevk> | and the interwebs |
| 12:06 | <Dashiva> | That's a feature |
| 12:06 | <Dashiva> | Makes it easier to transition to new protocols when there's no legacy around |
| 12:06 | <annevk> | you're on to something here |
| 12:07 | <annevk> | then we could finally deploy XHTML2 |
| 12:07 | <annevk> | and Cookie2 |
| 12:07 | <annevk> | and XSL:FO |
| 12:07 | <annevk> | and lots of other X-based specifications |
| 12:07 | <annevk> | the web would reborn |
| 12:07 | <annevk> | magical |
| 13:45 | <annevk> | "I'm afraid that is too meta-physical for me. I've been asked to edit the requirements document as part of the IETF process and that's what I'm attempting to do." is it just me or is the obvious follow-up question asking if he wants to jump in the pond? |
| 13:45 | <annevk> | incidentally, i recall Steven Pemberton justifying working on XHTML2 in much the same way |
| 14:39 | <Philip`> | http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2010/05/12/BUPJ1DDISH.DTL - "In a full-page ad [...] Adobe says, we love [...] HTML5" |
| 14:40 | Philip` | sadly can't find the actual ad |
| 14:40 | <annevk> | would be fun to see a picture of the ad, indeed |
| 14:50 | <krijnh> | Hey, this HTML5 thing.. Do you guys think this is going to be a mainstream thing? I really have my doubts about it! |
| 14:51 | <Philip`> | I don't know about this HTML5 thing |
| 14:51 | <Philip`> | That other HTML5 thing is pretty popular, though |
| 14:51 | <Philip`> | The one that's made up of CSS3 and Geolocation and so on |
| 14:51 | <krijnh> | I heard HTML5 also included Flash 10.1 in some definitions.. |
| 14:52 | <Dashiva> | It needs a better acronym, there's no X |
| 14:58 | <annevk> | i know i know, XHTML5! |
| 15:00 | <krijnh> | That's not catchy enough |
| 15:05 | <annevk> | the adobe stuff might be http://www.adobe.com/choice/ ? |
| 15:08 | <Philip`> | annevk: That and the ads seem to be part of the current Adobe-vs-Apple battle |
| 15:11 | <Philip`> | It's a nice battle since it's about who's the most open and most supportive of open standards like HTML5 |
| 15:12 | <krijnh> | I thought it was about who was most open about H.264 :) |
| 15:13 | <Dashiva> | It's about who has the stronger RDF |
| 17:02 | <MikeSmith> | othermaciej: you around? |
| 17:14 | <TabAtkins> | Hixie: Because I'm biased towards linked lists, just do insertion sort as each comes in. Worst case in n^2 time, but with a standard fairly uniform distibution of values it'll be fine, and dupe elimination comes along for free. |
| 17:19 | <Philip`> | Average case is O(n^2) time too |
| 17:19 | <TabAtkins> | Hm, yeah, you're right, since on average you'll just be adding it to the middle. |
| 17:23 | <Philip`> | If you have n total and m unique it'll be O(nm), vs O(n + m log m) for the hash/sort method, which isn't so good if m and n are large |
| 17:23 | <Philip`> | (and if they're not large then you wouldn't worry about performance at all) |
| 17:29 | <TabAtkins> | That then brings up the obvious question of, how large is it? |
| 17:32 | <Philip`> | -> <- this large |
| 17:33 | <ment> | Hixie: i would go with path-compressed tries. http://cr.yp.to/critbit.html |
| 17:38 | <TabAtkins> | You have to ensure that what you have is prefix-free in that case, though (which it likely is). |
| 17:43 | <ment> | TabAtkins: or you can just store strings with some kind of terminating character at the end (nul-byte in case of cstrings) |
| 20:30 | <annevk> | btw, karaoke plus ruby |
| 20:30 | <annevk> | http://www.flickr.com/photos/annevk/4601462252/ |
| 20:30 | <annevk> | including that animated effect with the letters |
| 20:30 | <annevk> | guess we'll need some new CSS features for that |
| 20:32 | <TabAtkins> | Oh, that wiping effect? Yeah, I've seen that in karaoke a lot. |
| 20:33 | <TabAtkins> | If we ever decide to handle that, though, it's certainly something just on the CSS side, with no effect on the captioning format, like you said. |
| 21:29 | <paul_irish> | Philip`: there were some reports of your font optimizer POST table mods messing with the printability. |
| 21:33 | <Philip`> | paul_irish: That's not unexpected |
| 21:33 | <paul_irish> | :) ok |
| 21:36 | <aho> | slightly off topic perhaps, but does anyone know why there isn't "rgba(#abc, 0.5)"? |
| 21:36 | <aho> | i'd happily trade that for that silly version which takes percentages :> |
| 21:36 | <TabAtkins> | Because people hate #rgb notation. ;_; |
| 21:36 | <TabAtkins> | But I and a few other people have been regularly arguing for an #rgba notation. |
| 21:37 | <TabAtkins> | s/people hate/some browser implementors/ |
| 21:37 | <AryehGregor> | I don't care whether I use hex or decimal, as long as I don't have to convert between them. |
| 21:37 | <AryehGregor> | "Because some browser implementors #rgb notation. ;_;" |
| 21:37 | <TabAtkins> | I've used hex colors for so long that I think about color in hex at this point. |
| 21:37 | <aho> | AryehGregor, well currently you do have to convert between them |
| 21:37 | <TabAtkins> | AryehGregor: So I write broken regexps. ^_^ |
| 21:38 | <aho> | i.e. you got some color in hex... and now you'd like to have it somewhat translucent |
| 21:38 | <Hixie> | Philip`: my N is low (1<=N<100) so the contant factors of setting up a hashmap seem high... isn't it just as easy and efficient to just build an array using binary search to find where to put things and a mem copy to move things around? |
| 21:38 | <TabAtkins> | But yeah, aho, I'm still trying to get #rgba added to the Color module, so we can write #06c8 and similar. |
| 21:39 | <aho> | that would be awesome |
| 21:39 | <aho> | :)~ |
| 21:39 | <TabAtkins> | Hixie: Are you locked to an array, or can you use a linked list? |
| 21:39 | <Philip`> | Hixie: If N < 100 then why are you caring about performance at all? |
| 21:39 | <aho> | i'd be also fine with something like rgba(#abc,0.5) though |
| 21:39 | <Hixie> | TabAtkins: how do i search a linked list? |
| 21:39 | <Hixie> | Philip`: there's a lot of them |
| 21:40 | <Philip`> | A lot of what? |
| 21:40 | <TabAtkins> | Hixie: I don't understand the context of that question. |
| 21:40 | <Hixie> | Philip`: lists to sort |
| 21:40 | <Philip`> | Oh, lots of short lists? |
| 21:40 | <Hixie> | TabAtkins: how do i construct the linked list in a sorted manner without walking on average half the list each time? |
| 21:40 | <Hixie> | Philip`: yeah |
| 21:40 | <TabAtkins> | You don't. You just do insertion sort and eat that cost, because the constant factors are low and the asymptotic behavior is irrelevant for such small cases. |
| 21:41 | <Hixie> | Philip`: i have a bunch of trees that contain strings, and for each tree i have to construct a sorted array of strings |
| 21:41 | <Hixie> | TabAtkins: i have an irrational aversion to searching for things by just walking a list :-) |
| 21:41 | <Philip`> | About hashmaps, "just as easy" depends on what language/library functionality you have available |
| 21:41 | <TabAtkins> | Hixie: Stop being irrational, then. |
| 21:41 | <Hixie> | :-) |
| 21:41 | <Philip`> | e.g. std::unordered_set<std::wstring> is trivial in C++ and writing code for an explicit binary search takes much more effort |
| 21:42 | <Lachy> | TabAtkins, what are the objections to the #rgba syntax? |
| 21:42 | <TabAtkins> | Lachy: Man, I dunno. Let me dig up the thread for you. |
| 21:42 | Philip` | isn't quite sure if it's really called std::unordered_set |
| 21:42 | <Hixie> | Philip`: code writinge effort in this case is not an isue |
| 21:42 | <AryehGregor> | Lachy, hard to tell at a glance whether something has three/four/six/eight characters after the #. Will take a long time to be usable compatibly. |
| 21:43 | <TabAtkins> | The latter is probably the main objection, since it's a convenience feature. I think it's pretty easy to tell 3/4/6/8 apart, though. |
| 21:43 | <Philip`> | Hixie: So "easy" is irrelevant? |
| 21:43 | <Lachy> | that last argument is bogus. It will just take longer if they keep delaying it. |
| 21:43 | <Lachy> | But I suppose the quickest way to get it in, is for some browser to implement it |
| 21:44 | <TabAtkins> | Hixie: Just write up a few possibilities and time. With lists that small constant factors that you have little control of will dominate, and so if you need efficiency you'll need to discover it experimentally. |
| 21:44 | <TabAtkins> | Lachy: Get to it. |
| 21:44 | TabAtkins | wonders who's the right person to ping for that on chrome team... |
| 21:45 | <aho> | <AryehGregor> Lachy, hard to tell at a glance whether something has three/four/six/eight characters after the #. <- well, rgba(#f00,0.4) is pretty easy to read and it's also very obvious :> |
| 21:45 | <TabAtkins> | Lachy: Actually, I think the main objection was that it would slow Color3's progression. Getting two of us to implement would kill that argument. |
| 21:46 | <Hixie> | Philip`: yeah |
| 21:46 | <aho> | (personally i also got somewhat used to using a normalized value for the alpha) |
| 21:46 | <Hixie> | Philip`: i'm just looking for something cheap in cpu and memory |
| 21:46 | <Lachy> | if distingishing 3/4/6/8 chars is the main objection, then maybe (though I think this is less ideal) the syntax could be like #369/A |
| 21:46 | <Hixie> | Philip`: primarily cpu |
| 21:46 | <Hixie> | Philip`: for 1<=N<100 |
| 21:46 | <Philip`> | How long are the strings? |
| 21:46 | <AryehGregor> | Lachy, that wouldn't conflict with other uses of /? |
| 21:47 | <aho> | i'd be also fine with that |
| 21:47 | <Lachy> | not in the color properties. |
| 21:47 | <AryehGregor> | Even in shorthand properties? |
| 21:47 | <Hixie> | TabAtkins: yeah, probably |
| 21:47 | <Lachy> | The / is used in 'font', where it wouldn't conflict |
| 21:47 | <TabAtkins> | Lachy: Rereading the latest thread on it, it appears the objections were (1) too late for Colors 3, it would slow down progression for a mere convenience feature, and (2) some implementors don't like #rgb notation at all, and so don't particular care to increase the usefulness of that syntax |
| 21:47 | <aho> | i don't really care... as long as i don't have to convert to dec or percentages (wtf) anymore, i'm fine |
| 21:47 | <Philip`> | It seems possible that string comparisons would be the most expensive operation so you'd want to minimise those |
| 21:47 | <Hixie> | Philip`: 1<=len(S)<20 |
| 21:48 | <AryehGregor> | Hixie, have you considered just buying better hardware? :) |
| 21:48 | <Lachy> | #rgb syntax is far superior to rgb() syntax for authors.; |
| 21:48 | <Philip`> | and shuffling smallarrays of pointers would be very quick |
| 21:48 | <Hixie> | AryehGregor: actually not an option in this case, but in any case it's more of a theoretical issue :-) |
| 21:48 | <Philip`> | s/la/l a/ |
| 21:48 | <Hixie> | Philip`: true |
| 21:48 | <TabAtkins> | Lachy: Yeah, I agree. Shrug. So go ping whoever you need to at Opera and get it in. ^_^ |
| 21:49 | <Hixie> | i'm surprised there isn't a well-known algorithm to solve this like there is for sorting constructed lists |
| 21:49 | <Philip`> | Maybe that means a trie would be best, since you'd only need to examine each character of an incoming string once, instead of comparing it against many others |
| 21:50 | <Hixie> | ooh, that's an interesting idea |
| 21:50 | <Hixie> | hadn't thought of that |
| 21:50 | <Lachy> | yeah, I think I know who's job it would be to implement it, but he's currently assigned to other tasks and has other more important tasks scheduled. But I'll see what I can do |
| 21:50 | <Philip`> | (ment already suggested a trie variant) |
| 21:51 | <TabAtkins> | Trie would probably be fine, since you won't be doing any more pointer-chasing than you would with a linked list, and the savings in comparisons might be significant. |
| 21:52 | <Hixie> | Philip`: yeah, i had opened the page he suggested but not read it yet :-) |
| 21:52 | <Philip`> | Since there's not much data it'd all fit in L1 and pointers shouldn't be too expensive, I guess |
| 21:52 | <aho> | #abcd #aabbccdd #abc/d #aabbcc/dd ... hmm... i think i prefer the one with slash a little bit |
| 21:52 | <aho> | but the pure one is fine too |
| 21:53 | <TabAtkins> | What's an average size for L1 caches these days? |
| 21:55 | <TabAtkins> | Man, I was wracking my brain for something I remembered for quickly sorting an array as it's built, but just realized that the algo I'm thinking of is for quickly *shuffling* an array as it is built. |
| 21:55 | <aho> | 64 kb + 64 kb (data + instructions) per core, i guess |
| 21:55 | <TabAtkins> | Ah, that's just fine then. With roughly 100 strings of 20 characters or less each, that's about 2k of data per set. So yeah, everything fits in L1 no problem. |
| 21:56 | <othermaciej> | I don't like that the A in the rgba() function syntax has a different scale than the other components |
| 21:58 | <TabAtkins> | I think it's pretty dumb that <alphavalue> is restricted to being a number in [0.0,1.0], and can't be a percentage like the other colors. |
| 21:59 | <aho> | i never used percentages for colors |
| 21:59 | <Philip`> | TabAtkins: http://en.wikipedia.org/wiki/Nehalem_(microarchitecture) says "32 KB L1 instruction and 32 KB L1 data cache per core; 256 KB L2 cache per core; 4–12 MB L3 cache shared by all cores" |
| 22:00 | <Philip`> | TabAtkins: You have to count all the pointers too, which are probably going to be larger than the actual character data |
| 22:00 | <Philip`> | but it sounds like it still wouldn't be a problem |
| 22:00 | <Philip`> | so there's no need to worry too much about optimising memory usage |
| 22:01 | <TabAtkins> | Hm? A pointer is 4-8 bytes. The strings will be 1-40 bytes, depending on encoding. |
| 22:01 | <Hixie> | (8 bytes, in this architecture) |
| 22:02 | <Philip`> | If it's a simple trie then I guess you need at least a pointer per node, which in the worst case is one per character |
| 22:02 | <TabAtkins> | Ah, right, per trie node. Yeah, then the pointers are more expensive. |
| 22:03 | Philip` | likes it when he can make code faster just by rearranging data and not having to do anything complicated like think about algorithms |
| 22:05 | <ment> | what problem are you trying to solve? |
| 22:10 | <Hixie> | ment: the same one i mentioned earlier |
| 22:10 | <Hixie> | Philip`: for a trie, it seems you need some sort of dictionary structure per node |
| 22:12 | <ment> | Hixie: i still haven't understand why don't you just sort them with qsort? |
| 22:12 | <othermaciej> | if you want to sort N items, just sort them |
| 22:12 | <othermaciej> | N log N is pretty good |
| 22:13 | <othermaciej> | qsort has good constants |
| 22:13 | <Philip`> | Depends if there's going to be lots of duplicates you want to get rid of before sorting |
| 22:13 | <ment> | why not remove duplicates _after_ sorting? |
| 22:13 | <othermaciej> | or use heapsort if you need very little memory |
| 22:13 | <othermaciej> | if you want to remove duplicates before sorting, just use a hashset |
| 22:13 | <othermaciej> | O(N) in number of entries |
| 22:14 | <othermaciej> | there's no way to sort and unique a list of strings that is faster than O(N log N) |
| 22:14 | <othermaciej> | (unless they are fixed length, then you can use a radix sort to sort I guess) |
| 22:14 | <TabAtkins> | Ha, beat me to it. |
| 22:15 | <Philip`> | ment: You might find everything is a duplicate of a single value in O(N) time, and then you avoid the whole O(N log N) sort |
| 22:15 | <TabAtkins> | Strings can be treated as fixed-length if you already know the longest length, and treat non-existent characters as sorted before any actual characters. |
| 22:15 | <AryehGregor> | "I'm not *strongly* opposed to the concepts that these semantic elements, attributes and controls add, but I do think that, in order to actually reach a W3C standard quickly, controversial additions that are likely to slow down progress or result in poor interoperability should be removed from the specification so that the W3C HTML working group can reach closure quickly." |
| 22:16 | <AryehGregor> | Is it just me, or is this kind of statement usually a self-fulfilling prophecy? |
| 22:16 | <Hixie> | ment: constructing an array, then sorting it, then removing duplicates, seems like something that could be optimised further |
| 22:16 | <othermaciej> | TabAtkins: that would be O(N * MAXLEN), so unless MAXLEN is much less than log N it doesn't much help |
| 22:16 | <othermaciej> | Hixie: is your input streaming in, or is it already in memory? |
| 22:16 | <TabAtkins> | Hixie: You don't need a dictionary for a trie. It's just a normal tree, with each link representing a single element of the lists. |
| 22:17 | <othermaciej> | a trie is still essentially N log N |
| 22:17 | <Hixie> | ment: i'm just surprised there aren't well-established algorithms for doing this :-) |
| 22:17 | <othermaciej> | don't use a fancy data structure when a simple one would do |
| 22:17 | <TabAtkins> | othermaciej: Right, but it's fun! |
| 22:17 | <Hixie> | TabAtkins: how do you store the connections at each node? |
| 22:17 | <ment> | Philip`: first, there's three-way qsort. second, you would need a really large amount of data with duplicates to speed things up (it would only complicate the code) |
| 22:17 | <othermaciej> | there are - unique using a dictionary, then sort using a common sort |
| 22:17 | <TabAtkins> | Hixie: An array of pointers. |
| 22:17 | <ment> | Hixie: there are! qsort :) |
| 22:17 | <Hixie> | othermaciej: it's in memory (in a tree data structure) |
| 22:17 | <othermaciej> | Hixie: what kind of tree? |
| 22:17 | <Hixie> | ment: for constructing the array while sorting it, i mean |
| 22:18 | <Hixie> | othermaciej: on what axis are you asking for the trees to be described? |
| 22:18 | <othermaciej> | if the tree is indexed by the string in question, then an inorder traversal will give you back the strings in sorted order |
| 22:18 | <Hixie> | TabAtkins: then you're back to walking a list to find things :-P |
| 22:18 | <ment> | Hixie: do you need it to be 1) with low latency (and with intermidiate results available) 2) able to cope with large amount of data 3) high speed ... ? just give some conditions |
| 22:18 | <othermaciej> | that's O(N) |
| 22:18 | <othermaciej> | Hixie: any - "it's a tree" is very little information |
| 22:19 | <TabAtkins> | Hixie: Hm? No, if you have a set alphabet the strings are constructed from, you just make an array of that size and you can grab the appropriate one with a simple index. |
| 22:19 | <ment> | othermaciej: trie is not 'N log N', trie is O(1) if implemented right |
| 22:19 | <ment> | erm, O(N) |
| 22:19 | <othermaciej> | is it a binary tree? a b-tree? something else? are these the strings to the key or not? |
| 22:19 | <othermaciej> | ment: building the trie isn't O(N) |
| 22:20 | <ment> | othermaciej: erm I mean O(N) where N is sum of lenghts of the keys |
| 22:20 | <Hixie> | othermaciej: it's just a regular tree, like a DOM tree; the strings are just annotations at each node and have nothing to do with the structure of the tree |
| 22:20 | <ment> | othermaciej: but you wouldn't get better result with sort anyway as comparsion or varlen keys isn't really O(1) |
| 22:20 | <ment> | *of |
| 22:20 | <othermaciej> | Hixie: so my suggestion is, make an array and a set, visit each tree node, check if string is in set, if not, append to the array |
| 22:20 | <othermaciej> | then sort the array |
| 22:20 | <othermaciej> | if that is too slow or uses too much memory, then you can worry about whether you need a fancy algorithm |
| 22:20 | <Hixie> | TabAtkins: um, i'm not creeating a 256-entry (or 0x10FFFF-entry!) array at each node of a trie, that would take insane amounts of memory :-P |
| 22:21 | <ment> | Hixie: my suggestion is qsort it, then remove the duplicates |
| 22:21 | <othermaciej> | sorting before removing duplicates could use less memory in theory but is probably slower |
| 22:21 | <Hixie> | man creating an array then sorting it seems so silly |
| 22:21 | <ment> | you don't have to, you can save the state-transition table in hashmap :) |
| 22:21 | <Hixie> | ment: that's what i said earlier |
| 22:22 | <Hixie> | ment: each node of a trie requires some sort of dictionary |
| 22:22 | <TabAtkins> | Hixie: Heh, just estimate the minimum and maximum character used and establish an array that wide. |
| 22:22 | <othermaciej> | Hixie: you could build a balanced binary tree instead, but then building the tree takes longer than building the array + sorting the array |
| 22:22 | <Hixie> | ment: TabAtkins was disagreeing |
| 22:22 | <ment> | but you can use one dictionary for all states |
| 22:22 | <othermaciej> | basic rule of programming: never use a fancy data structure when a simple one would do |
| 22:22 | <ment> | and access it with composed key (state, char) |
| 22:22 | <TabAtkins> | Hixie: Though a linked list of pointers would be better, since it will be sparse past the root node. |
| 22:22 | <Hixie> | othermaciej: i'm just surprised there isn't some variant on sorting algorithms that basically sorts as the array is constructed instead of doing it as a two-step process |
| 22:22 | <othermaciej> | if you haven't tried the simple solution first, you are wasting all our time and are a bad software engineer |
| 22:23 | <ment> | Hixie: it is :) insert sort |
| 22:23 | <othermaciej> | Hixie: a balanced binary tree self-sorts, but it's not really faster |
| 22:23 | <Hixie> | ment: insertion sort still acts on a pre-built array unless we're talking about different things |
| 22:23 | <othermaciej> | true, insertion sort will do it, but that's O(N^2) |
| 22:24 | <Hixie> | othermaciej: i agree entirely that using complex data structures is silly here, hence my pushback on the ideas of using tries and so forth |
| 22:24 | <othermaciej> | you can use insertion sort in the course of inserting |
| 22:24 | <ment> | Hixie: no, you walk down sorted list and insert it before first larger key |
| 22:24 | <othermaciej> | Hixie: why your pushback on building an array and then sorting it then? |
| 22:24 | <othermaciej> | that's the obvious CS101 solution |
| 22:24 | <TabAtkins> | Hixie: No, insertion sort works fine. That's why I suggested it beforehand. ^_^ You need a linked list, not an array, though, to avoid data-moving penalties. |
| 22:24 | <othermaciej> | if you haven't tried that, you are wasting all our time |
| 22:24 | <Hixie> | othermaciej: no push back there, i'm just saying i'm surprised there's no better solution |
| 22:24 | <Hixie> | othermaciej: it's basically what i had gotten to before asking here |
| 22:24 | <othermaciej> | sorting is N log N |
| 22:24 | <ment> | TabAtkins: data moving while traversing is cheap |
| 22:25 | <othermaciej> | (unless you have a special case amenable to radix sort or the like) |
| 22:25 | <Hixie> | ment: walking the whole list each time just seems obviously suboptimal |
| 22:25 | <Hixie> | or half the list |
| 22:25 | <Hixie> | on average |
| 22:25 | <TabAtkins> | ment: Not in the situation you'd have here, where you would traverse part of the array, and then ahve to move the rest. |
| 22:25 | <TabAtkins> | ment: That's guaranteeing a full-price n^2 cost. |
| 22:26 | <othermaciej> | insertion sort is a poor solution here |
| 22:26 | <ment> | TabAtkins: what if you move while traversing from the back? |
| 22:26 | <othermaciej> | one O(N^2) pass is not better than an O(N) pass followed by an O(N log N) pass |
| 22:26 | <ment> | Hixie: do you need it to be high-speed for 10000 or more keys? |
| 22:26 | <TabAtkins> | othermaciej: It is if the N is very small (which it is here, roughly 100 strings). |
| 22:27 | <TabAtkins> | othermaciej: Or rather, it can be, if the constant factors are small enough for the n^2. |
| 22:27 | <othermaciej> | they are not smaller than the constant factors for vector append and quicksort |
| 22:28 | <othermaciej> | and if your problem set size is 100, then if you are spending time optimizing it at all you're probably wasting effort |
| 22:28 | <TabAtkins> | othermaciej: Individual problems are roughly 100, but if you have a bunch of problems like that then optimization can make sense. |
| 22:28 | <othermaciej> | (unless you do it over and over) |
| 22:29 | <othermaciej> | optimization doesn't make sense until you measure |
| 22:29 | <TabAtkins> | But really, I said before that at problem sizes this small you can't establish efficiency through theory, and really just need to do timings. |
| 22:29 | Hixie | wasn't trying to optimise, just asking if there was some obvious solution intended for this case that he was overlooking :-) |
| 22:29 | <othermaciej> | you already found the obvious solution |
| 22:29 | <Hixie> | apparently |
| 22:30 | <othermaciej> | there may be marginally faster solutions depending on context, but none of them are obvious, and the obvious solution is not at all bad |
| 22:30 | <Philip`> | The obvious solution is always some combination of sorts and trees and hashmaps, whatever the problem is |
| 22:30 | <Philip`> | and usually works well enough |
| 22:31 | <othermaciej> | sometimes you need a crazy data structure |
| 22:31 | <othermaciej> | not often though |
| 22:31 | <ment> | sometimes you need word-encoded hash-table indexed by tree shape |
| 22:32 | <ment> | btw do css* working groups have irc channels? |
| 22:33 | <Philip`> | Overoptimisation of underspecified problems is always fun, though |
| 22:33 | <TabAtkins> | ment: We have #css on the w3 server, but that's not really for CSS discussion, just working group stuff. |
| 22:35 | <ment> | ah, i was looking for a place where i can threaten people designing new css3 collection of specs |
| 22:35 | <TabAtkins> | Which specs? I can be threatened here without you having to lift an additional finger. |
| 23:12 | <volkmar> | in html4, legend elements had an align attribute they don't have anymore in html5, that's a regression or i'm missing something ? |
| 23:15 | <othermaciej> | use CSS |
| 23:25 | <volkmar> | othermaciej: i don't know the policy about backward compatibility but that means someone using "aglign=bottom" (don't know if that's valid) which should do something with HTML4 will do nothing with HTML5 |
| 23:26 | <volkmar> | imo, that's an issue |
| 23:32 | <Hixie> | look in the "obsolete features" section |
| 23:32 | <Hixie> | it's defined there |
| 23:32 | <Hixie> | and in the rendering section |
| 23:34 | <KaOSoFt> | Can I do something like this? |
| 23:34 | <KaOSoFt> | <label for="candidato">Primer grupo</label> |
| 23:34 | <KaOSoFt> | <img alt="Fotograf�as de Tal persona y tal persona" height="240" id="candidato" src="grupo.jpg" width="320" /> |
| 23:34 | <othermaciej> | volkmar: it's supported but not valid |
| 23:35 | <volkmar> | othermaciej: ok, then that's the backward policy: supported but not valid |
| 23:35 | <volkmar> | thanks :) |
| 23:36 | <othermaciej> | that's true for a lot of things in HTML5 |