| 00:01 | <Philip`> | hsivonen: You have been corrupted by your years in the presence of Hixie's Ring - it bends you to its will, and it will never let go unless you cast it into the flames |
| 00:02 | <takkaria> | I thought you were joking for a minute, there |
| 00:02 | <Philip`> | (Hmm, I think the metaphor broke down before the end of the sentence) |
| 00:03 | <annevk> | It's interesting that the blog from Gregory is full of <b> and <i> ( http://my.opera.com/oedipus/blog/ ) |
| 00:03 | <annevk> | while he claims they're bad for accessibility |
| 00:04 | <annevk> | (fwiw, this is about markup in the posts he writes) |
| 00:04 | <hsivonen> | Philip`: no comment after looking it up in urbandictionary.com |
| 00:06 | annevk | is confused |
| 00:06 | <webben> | annevk: How does Opera's blogging thingy generate emphasis? And how does it generate italic? |
| 00:06 | <webben> | (I mean, what is the UI.) |
| 00:06 | <annevk> | dunno |
| 00:06 | <webben> | I rather doubt it's under Gregory's control. |
| 00:07 | <hsivonen> | hmm. perhaps the ad hominem wasn't intended to be as dirty as I thought. carry on |
| 00:07 | <annevk> | webben, that's besides the point though |
| 00:07 | <webben> | annevk: It is? |
| 00:07 | <annevk> | webben, why would he use them? |
| 00:07 | <webben> | Why would he use Opera's blogging software? |
| 00:07 | <webben> | Dunno. I've never used it. |
| 00:07 | <annevk> | no, why would he use the italic and bold markup |
| 00:07 | <Philip`> | hsivonen: Hmm, urbandictionary.com has, uh, cruder meanings than I was thinking of |
| 00:08 | <webben> | annevk: What makes you think he has any effective control of what Opera's blogging software generates? |
| 00:09 | <annevk> | webben, I've no idea what you're talking about |
| 00:09 | <hsivonen> | Philip`: I was just figuring out what he mean with his footnote about connotations and that was what I found. |
| 00:09 | <hsivonen> | meant |
| 00:09 | <webben> | annevk: (NB I know zilch about Opera's blogging software, but it could for all I know be like blogger. Blogger doesn't have em and strong as options.) |
| 00:09 | <annevk> | it's not about options, it's about using them in the first place |
| 00:09 | <annevk> | obviously they have some sort of effect, even in the software he's using |
| 00:10 | <webben> | annevk: Then I don't understand your point (or perhaps you've misunderstood the problem with <i>, I'm not sure.) |
| 00:11 | <annevk> | I suppose, I already said your remark was besides the point... |
| 00:11 | <webben> | That is to say: the problem with i is ambiguous semantic; but some effect in UAs may be better than no effect at all. |
| 00:12 | <annevk> | all elements in HTML have ambiguous semantics afaict... |
| 00:12 | <annevk> | anyway, bedtime |
| 00:12 | <webben> | annevk: good night |
| 00:18 | hsivonen | finds "divide and conqueror the current crop of HTML5 manglers" in the html4all archives... |
| 00:20 | <takkaria> | url? |
| 00:21 | <hsivonen> | takkaria: hmm. they don't seem to have an easy facility of mapping message-ids to URLs. |
| 00:21 | <hsivonen> | takkaria: http://html4all.org/pipermail/list_html4all.org/2007-August/000054.html |
| 00:21 | <takkaria> | ta |
| 00:23 | <webben> | Interesting. A quick test shows Opera's blogging software has only B and I buttons, and emits <i> for I and <strong> for B. |
| 00:24 | <webben> | unless I'm missing something (easily possible) it doesn't offer a way to enter HTML directly |
| 00:40 | <Hixie> | hsivonen: wow, that's awesome in so many ways |
| 01:02 | <Hixie> | http://html4all.org/pipermail/list_html4all.org/2007-August/000016.html |
| 01:02 | <Hixie> | it's interesting to note how different his opinions are from those that the whatwg used as a foundation (as described in the opera/mozilla position paper) |
| 01:13 | <jruderman> | Hixie: does HTML5 specify https://bugzilla.mozilla.org/show_bug.cgi?id=395597 either way? |
| 01:14 | <jruderman> | (if set innerHTML on a new element and *then* put that element into the document, do <script>s in the innerHTML execute?) |
| 01:23 | <Hixie> | the spec does cover it |
| 01:29 | <Hixie> | jruderman: search for "If the parser was originally created for the HTML fragment parsing algorithm, then mark the script element as "already executed"" |
| 01:44 | <jruderman> | so it's a bug, then |
| 01:44 | <jruderman> | in gecko |
| 01:45 | <jruderman> | thanks |
| 01:52 | <Hixie> | unless you think we should change the spec, yeah |
| 01:53 | <jruderman> | the spec seems sane to me, and it matches ie and opera according to the bug report |
| 01:54 | <Hixie> | cool |
| 01:55 | <jruderman> | "already executed" might not be the best name for the flag, though |
| 01:55 | <Hixie> | well originally it was just set when the <script> element was executed |
| 01:56 | <Hixie> | i added innerHTML support later |
| 01:56 | <Hixie> | it's true it is no longer a hugely accurate name |
| 02:57 | othermaciej | wonders how that works in Safari |
| 07:19 | <boogs> | Does anyone know how in Hixie's most recent offline proposal the last caveat-paragraph (the same url shows up in two applications) can happen? |
| 07:20 | <boogs> | I thought it should be impossible since the first time a page shows up with it's application URL pointing to someplace else it is an error, or removed from the prior place. |
| 07:20 | <Hixie> | consider this case: |
| 07:20 | <Hixie> | go to http://example.com/a |
| 07:20 | <Hixie> | it has an application="a.manifest" |
| 07:20 | <Hixie> | you load a.manifest and it says to load http://example.com/b |
| 07:21 | <Hixie> | you load http://example.com/b and it has application="a.manifest" |
| 07:21 | <Hixie> | then, totally separately, you go to http://example.com/c, and it has application="c.manifest", which also says to load http://example.com/b |
| 07:21 | <Hixie> | when you load http://example.com/b now, the server sends back a file with application="c.manifest". |
| 07:22 | <Hixie> | now, you go to http://example.com/b -- which app cache should it load from? |
| 07:22 | <boogs> | Right, ok, I agree that can happen. |
| 07:22 | <boogs> | Right now this is a bug in Gears, the result is non-deterministic, which is bad. |
| 07:23 | <boogs> | our only idea was to make the second one an error. |
| 07:24 | <Hixie> | making it an error doesn't say what should happen :-) |
| 07:24 | <boogs> | I mean, it would be a runtime error, the capture would fail. |
| 07:24 | <Hixie> | so you couldn't load http://example.com/c ? |
| 07:24 | <Hixie> | or rather, couldn't cache it? |
| 07:24 | <boogs> | right. |
| 07:25 | <Hixie> | seems a bit draconian |
| 07:25 | <boogs> | It seems like the other option is to invalidate the first application. |
| 07:25 | <boogs> | otherwise, you lose atomicy, right? |
| 07:25 | <Hixie> | especially if the http://example.com/a was a mistake |
| 07:26 | <Hixie> | my proposal was just to say that the last one wins, iirc |
| 07:26 | <Hixie> | i don't think it's a huge issue |
| 07:26 | <Hixie> | it's not like it'll happen much; maybe occasionally in development |
| 07:26 | <Hixie> | but then you want the last one to win anyway |
| 07:26 | <boogs> | it is a problem |
| 07:27 | <boogs> | so in the current proposal, if a resource is in more than one app caches, the browser loads it from the cache that got it last? |
| 07:27 | <Hixie> | you mean if you go there as a top-level page? |
| 07:27 | <boogs> | let's just say a non-top-level thing for now. |
| 07:27 | <Hixie> | or do you mean if you load it in an <img> or <iframe> or something? |
| 07:27 | <boogs> | a js file. |
| 07:28 | <Hixie> | non-top-level always loads from the current top-level-page's own app cache |
| 07:28 | <Hixie> | or the network if it's not there |
| 07:28 | <boogs> | I see, it wasn't clear from the new proposal that you were keeping that feature from the old one. |
| 07:29 | <Hixie> | ah, my bad |
| 07:29 | <Hixie> | yeah |
| 07:29 | <Hixie> | otherwise there's not much point having multiple caches :-) |
| 07:30 | <boogs> | Another question: why have the slurp feature at all, if you're going to have manifests? |
| 07:30 | <boogs> | it seems so mushy |
| 07:30 | <boogs> | I mean, I can construct cases where I want XHR to go to the cache |
| 07:31 | <Hixie> | well, the slurp feature is useful in the one-page-app case, but also, you don't want to have to specify every dependency, you only want to need to specify the other top-level pages and the per-page or only occasional dependencies |
| 07:32 | <Hixie> | like, an image that you don't always preload |
| 07:32 | <Hixie> | or a stylesheet that you only use occasionally |
| 07:32 | <Hixie> | why would you want XHR to go from the cache? |
| 07:32 | <Hixie> | (the app cache, that is, vs the general network layer cache) |
| 07:32 | <boogs> | well we actually do that in a gears unit test, to test that the cache is working |
| 07:32 | <boogs> | does that count? :) |
| 07:33 | <Hixie> | no :-P |
| 07:33 | <Hixie> | use a dynamically added <script> or something :-P |
| 07:33 | <boogs> | well, if you want to get the text contents of some resource, to process it. |
| 07:33 | <boogs> | like a text file. |
| 07:34 | <boogs> | maybe it's config. |
| 07:35 | <Hixie> | just load it once from the network and cache it in the database, or cookies |
| 07:35 | <boogs> | Also, going the other way, like I said, it is common to use a new Image() to ping a server. |
| 07:35 | <boogs> | In which case you don't want it to go the app cache. |
| 07:36 | <Hixie> | since you have to rewrite your apps for this anyway, it doesn't seem bad to require authors to use a more appropriate pinging method |
| 07:36 | <Hixie> | creating an image is really not an appropriate pinging method |
| 07:36 | <Hixie> | since it has nothing to do with images |
| 07:36 | <Hixie> | no? |
| 07:36 | <boogs> | That *is* the pinging method we are using in new apps. I guess it is just more convenient than xhr |
| 07:37 | <boogs> | What if it was just that it slurped the things that were in the html markup, not dynamically created things. That might be crisper. |
| 07:37 | <Hixie> | that's basically impossible to do from an architecture point of view |
| 07:38 | <Hixie> | dynamically created from the parser vs dynamically created by script should work the same |
| 07:38 | <Hixie> | (not even considering things like innerHTML, which blur the lines yet further) |
| 07:38 | <boogs> | hm, ok. |
| 07:38 | <Hixie> | i don't really understand why new Image() is considered a good way of pinging a server |
| 07:39 | <Hixie> | it's not an image... why would you use Image()? |
| 07:39 | <boogs> | We do ping an image. |
| 07:39 | <Hixie> | that's like using a table for layout purposes... |
| 07:39 | <boogs> | x.gif, or whatever |
| 07:39 | <boogs> | or the google logo |
| 07:39 | <Hixie> | why? |
| 07:39 | <Hixie> | why not just grab an actual status file? |
| 07:39 | <boogs> | because xhr can fail in a variety of dramatic ways on different browsers and catching all of them is difficult. |
| 07:39 | <boogs> | where as image just fires onerror no matter what happened. |
| 07:39 | <Hixie> | sounds like something we should fix |
| 07:40 | <Hixie> | we could also just provide a server-status-pinging api |
| 07:40 | <Hixie> | what is it you want to know? whether you're online? |
| 07:40 | <boogs> | Whether our server is alive. |
| 07:41 | <Hixie> | to sync with the server? |
| 07:41 | <boogs> | yes. |
| 07:41 | <Hixie> | hm |
| 07:41 | <boogs> | We try to not do this ever, but there are cases where you need to know. |
| 07:41 | <boogs> | For example, the login screen must be different if you can't reach the server. |
| 07:41 | <boogs> | It is useless to show the password box. |
| 07:42 | <Hixie> | a login screen while offline? |
| 07:42 | <boogs> | A pick-which-user-you'd-like-to-be screen |
| 07:42 | <boogs> | profile picker |
| 07:42 | <Hixie> | wouldn't you have to be logged in for the app to be cached in the first place? |
| 07:42 | <Hixie> | ew |
| 07:42 | <Hixie> | isn't that what the os profile picker is for? |
| 07:42 | <boogs> | do people use that? :) |
| 07:43 | <boogs> | having multiple users on the same os session is a fact of life for web apps I think. |
| 07:44 | <Hixie> | hm, that wasn't on the list of reqs :-/ |
| 07:44 | <Hixie> | i have no idea how to handle that well |
| 07:44 | <boogs> | you don't need to spec for it |
| 07:44 | <boogs> | It is possible to provide the feature without any changes to your spec, it just means webdevs need to do some ugly things. |
| 07:45 | <Hixie> | wanna avoid ugly things if possible :-) |
| 07:46 | <boogs> | Anyway, all of this is workaroundable. If you make the image ping trick not work, we can just use xhr. My main point was that it seems mushy to me that some requests silently get cached, others don't. |
| 07:46 | <Hixie> | well the idea is they all get cached except XHR (that being the official way to talk to servers) and anything that isn't a GET (because i don't really want to think about what it means to cache a POST or DELETE) |
| 07:47 | <Hixie> | would be interesting to have an explicit way to check for the server though |
| 07:47 | <boogs> | But only during load, right? |
| 07:47 | <boogs> | (that is what the previous proposal said) |
| 07:47 | <Hixie> | i don't think there's anything limited to load, in either proposal |
| 07:48 | <boogs> | I think the previous one said that all requests that were GET during load were slurped. |
| 07:48 | <Hixie> | no, all GET requests always |
| 07:48 | <Hixie> | (maybe when the server gets the manifest (changed or not) we fire an event saying "server up"?) |
| 07:49 | <Hixie> | uh, when the UA gets the manifest |
| 07:49 | <boogs> | Maybe. |
| 07:50 | <boogs> | So if you always capture GETs, that means you can get an inconsistent application. |
| 07:50 | <boogs> | I guess that can happen anyway though, if the server restarts during capture. |
| 07:50 | <boogs> | or if new files show up or whatever, and apps will have to be robust to that. |
| 07:50 | <Hixie> | how would you get an inconsistent application? |
| 07:51 | <boogs> | well if you're running v1 on your server, and then you push v2, and then an app requests a resource dynamically. |
| 07:51 | <boogs> | it will get resource(v2) |
| 07:51 | <boogs> | but it will be running app(v1) |
| 07:51 | <Hixie> | oh yeah, but that'll happen today anyway, and also happens regardless of whether we limit it to before load or after load |
| 07:52 | <boogs> | gears prevents this by checking the manifest version before and after update |
| 07:52 | <Hixie> | how does that prevent it? |
| 07:52 | <Hixie> | does it just not show the app in that case? |
| 07:52 | <Hixie> | that seems like it would slow page load dramatically |
| 07:52 | <Hixie> | (in the initial load case_ |
| 07:52 | <Hixie> | ) |
| 07:52 | <boogs> | updates are not linked to page load |
| 07:52 | <boogs> | in gears |
| 07:53 | <boogs> | they happen completely in the background |
| 07:53 | <Hixie> | so what happens if i visit http://example.com/ the first time |
| 07:53 | <boogs> | it loads it from the network |
| 07:53 | <Hixie> | and an update is pushed at the same time |
| 07:53 | <boogs> | you have to call an api to capture in gears |
| 07:53 | <Hixie> | ah |
| 07:53 | <boogs> | it doesn't happen automatically |
| 07:53 | <boogs> | and then updates happen automatically after that |
| 07:54 | <boogs> | I had another question: what happens if the upgrader fails? |
| 07:56 | <Hixie> | re the earlier question, we could make this system also check the manifest before and after and check they're the same, and throw everything out and retry if they're not |
| 07:56 | <Hixie> | what kind of failure? script syntax error so it never responds to the other pages? or? |
| 07:57 | <boogs> | right, like a script error at parse or runtime, or maybe a database error updating the schema |
| 07:59 | <Hixie> | a database error updating the schema will work the same as in the only-online-app case |
| 07:59 | <Hixie> | an error in the script, though, can work gracefully -- the other pages, when they try to communicate with the upgrader, will see something bad happened (e.g. cos it doesn't respond) and will be able to report it, or ignore the upgrader |
| 07:59 | <boogs> | to put it another way, is the update successful before or after the updater? |
| 08:00 | <boogs> | sorry, upgrader |
| 08:00 | <Hixie> | for the purposes of checking consistency? |
| 08:00 | <Hixie> | before |
| 08:00 | <Hixie> | well |
| 08:00 | <Hixie> | hmm |
| 08:02 | <Hixie> | i guess it would only work in the manifest case |
| 08:02 | <Hixie> | the consistency check, i mean |
| 08:02 | <Hixie> | since in the other case, you're already running script |
| 08:04 | <boogs> | It seems like it simplifies things to just have the first page load with the new code responsible for doing the update. |
| 08:04 | <Hixie> | if you have the app open in multiple tabs, how do they know which is the first? |
| 08:05 | <boogs> | Whichever one reloads first. |
| 08:05 | <Hixie> | they all reload at the same time |
| 08:05 | <boogs> | You can use db transactions (if you keep your local state in the db) to serialize them. |
| 08:05 | <boogs> | anyway that is what we do. |
| 08:05 | <Hixie> | i guess you could |
| 08:05 | <Hixie> | still seems nice to be able to negotiate |
| 08:06 | <Hixie> | e.g. you might not want to reload the whole page, but still have the db update |
| 08:06 | <Hixie> | in which case you might want to talk to the upgrader to determine what needs to happen |
| 08:06 | <boogs> | Yeah, it's a neat idea. |
| 08:06 | <Hixie> | i guess we don't need the upgrader concept, just seemd like a useful thing to have if we were having the simple one-page case slurp anyway |
| 08:07 | <Hixie> | i mean, it's basically free at that point |
| 08:07 | <Hixie> | and seems easy enough to implement |
| 08:07 | <boogs> | What you mean because you already had to implement the hidden window thing? |
| 08:08 | <Hixie> | yeah assuming we still support the one-page case the way it's described, with no manifest, the upgrader in the manifest case seems to be a minor addition |
| 08:08 | <Hixie> | maybe i'm just trying to be too clever for my own good though |
| 08:09 | <boogs> | It's a nice touch to be able to communicate between the windows. |
| 08:09 | <boogs> | That solves one problem in gears because right now if window 1 upgrades the schema, window 2 doesn't know and can corrupt it by accessing it with old code. |
| 08:09 | <Hixie> | yeah |
| 08:10 | <boogs> | We had wanted to solve that by having versioned db connections |
| 08:10 | <Hixie> | i've added a note about an event to fire with the manifest is fetched (whether changed or not) |
| 08:10 | <Hixie> | to my notes |
| 08:10 | <Hixie> | fwiw |
| 08:10 | <Hixie> | the other issues was ensuring consistency during an update, right? |
| 08:10 | <boogs> | yes, it would be nice to check the manifest again after update. |
| 08:11 | <boogs> | i guess it's then on the developer to know that if they fetch things after load, that can make their app inconsistent. |
| 08:11 | <boogs> | and they should check that. |
| 08:11 | <Hixie> | yeah |
| 08:12 | <Hixie> | what's the alternative? just fail the later loads? |
| 08:12 | <boogs> | I suppose you could recheck the manifest before each later load :-/ |
| 08:12 | <boogs> | and after :P |
| 08:12 | <Hixie> | heh |
| 08:13 | <boogs> | aight, i'm off. thanks for your time. |
| 08:13 | <Hixie> | later |
| 08:13 | <othermaciej> | boogs: if you are doing anything that would make the autoslurping unworkable... |
| 08:13 | <Hixie> | boogs: and thank _you_! |
| 08:13 | <othermaciej> | boogs: you can always use a manifest |
| 08:14 | <othermaciej> | it doesn't seem to hurt to also have it |
| 08:14 | <boogs> | othermaciej: yeah, i liked the slurping a lot from the first proposal because it seems great for new developers. |
| 08:14 | <othermaciej> | the question is just whether any real apps are simple enough to work that way |
| 08:15 | <othermaciej> | I guess it is nice for prototyping |
| 08:15 | <boogs> | we have a lot of disagreements on our team about whether it is more of a help or a hinderance. |
| 08:15 | <boogs> | and also the guys say that it seems implement for gears, so we might have to skip it either way. |
| 08:16 | <othermaciej> | pardon? |
| 08:16 | <boogs> | pardon which? |
| 08:16 | <othermaciej> | "and also the guys say that it seems implement for gears" ==> parse error |
| 08:16 | <boogs> | heh |
| 08:16 | <boogs> | seems hard to implement |
| 08:17 | <othermaciej> | ah |
| 08:17 | <othermaciej> | I have to get to bed |
| 08:17 | <boogs> | me too. |
| 08:17 | <othermaciej> | I'm gonna take the train to work tomorrow so I have quiet time to read the relevant proposals |
| 08:17 | <othermaciej> | nini |
| 08:17 | <boogs> | toodles. |
| 09:50 | <hsivonen> | Philip`_: re: th in layout tables: http://www.spiderrobinson.com/ looks like SEO. yay for trustworthy semantics |
| 09:51 | <hsivonen> | eww. http://blindconfidential.blogspot.com/ is hard to read visually due to all the <br>s |
| 09:54 | <Lachy> | comment 42 is interesting http://www.456bereastreet.com/archive/200709/can_the_alt_attribute_be_omitted_without_hurting_accessibility/#comment42 |
| 09:55 | <Lachy> | though I'm not sure how a UA could treat img without alt any different from <img noalt> - I thought it was just a validation indicator |
| 09:56 | <zcorpan> | they might want to treat altless <img> the same as alt="" because of the many decorative images that don't have alt, perhaps? |
| 09:57 | <Lachy> | maybe, but there are also a lot of existing content images without alt as well and adding noalt now won't fix them all |
| 09:57 | <hsivonen> | suppose J. Random Hacker is a dev on a Web app team |
| 09:57 | <zcorpan> | Lachy: true |
| 09:58 | <hsivonen> | the app gets images from users and external database or whatever source outside the policy enforcement control of the app devs |
| 09:58 | <hsivonen> | marketing has just advertised the app as being standards compliant |
| 09:58 | <hsivonen> | the manager tells the devs to make sure the pages validate |
| 09:59 | <hsivonen> | now the devs are going to generate whatever the spec says is OK |
| 09:59 | <hsivonen> | if the spec says it is no alt attribute, they'll do that |
| 10:00 | <hsivonen> | if the spec says it is some alt attribute, they'll put some junk in there |
| 10:00 | <hsivonen> | if it says noalt, they'll just do that |
| 10:00 | <hsivonen> | in the end, noalt would just get autogenerated |
| 10:00 | <hsivonen> | so you couldn't use it for determining how essential an image is |
| 10:01 | <hsivonen> | just that the generator couldn't tease an alt out of the image source |
| 10:01 | <hsivonen> | now how is noalt better than no alt? |
| 10:01 | <hsivonen> | for UAs |
| 10:01 | <Lachy> | so it really depends which alternative can help make the best of a bad situation for the end user? |
| 10:02 | <hsivonen> | Lachy: yes |
| 10:03 | <hsivonen> | actually s/generate whatever the spec says is OK/whatever passes the validator with the least effort/ |
| 10:03 | <othermaciej> | I don't know if noalt would be useful to UAs |
| 10:03 | <othermaciej> | the way it would be helpful is for thoughtful content authors or web app developers who want to make sure that every image has alt text that possibly could |
| 10:03 | <othermaciej> | and who want to use a validator to ensure that |
| 10:04 | <othermaciej> | if omitting alt is not allowed, it can't be a validator error |
| 10:04 | <othermaciej> | it could be a validator warning |
| 10:04 | <othermaciej> | but if sometimes you meant to omit alt and other times it was just a mistake, in the same document, then the warning is not very helpful |
| 10:04 | <othermaciej> | because you can't get the warning count to 0 so it's hard to notice new ones creeping in |
| 10:04 | <othermaciej> | I don't know if that is enough justification for adding an attribute to the language |
| 10:05 | <othermaciej> | but it seems like it would be a real benefit |
| 10:05 | <othermaciej> | my mental analogy is to warnings from a C/C++ compiler |
| 10:05 | <othermaciej> | any warnings that can be practically avoided in all cases, we just turn on -Werror and they never happen |
| 10:05 | <othermaciej> | warnings that can't always be practically avoided we basically don't benefit from |
| 10:05 | <othermaciej> | to draw a more concrete analogy |
| 10:05 | <othermaciej> | gcc will warn on this: |
| 10:06 | <othermaciej> | if (x = someFunc()) { /.../ } |
| 10:06 | <othermaciej> | (because you probably meant ==) |
| 10:06 | <othermaciej> | but not on this: |
| 10:06 | <othermaciej> | if ((x = someFunc())) { /*...*/ } |
| 10:06 | <othermaciej> | because the extra parens are so unlikely to occur by accident that clearly you did it to say you really meant to do an assignment there |
| 10:07 | othermaciej | hopes he is still connected |
| 10:07 | <zcorpan> | you are :) |
| 10:07 | <othermaciej> | zcorpan: ok I guess I just bored everyone then :-) |
| 10:07 | <hsivonen> | othermaciej: gcc warnings are for human programmers |
| 10:07 | <hsivonen> | othermaciej: not code generators |
| 10:08 | <othermaciej> | hsivonen: we build our generated source files with full warnings too, to catch bugs in the code generators |
| 10:08 | <hsivonen> | I compiled genx for python yesterday and got and awful lot of warnings but didn't care |
| 10:09 | <othermaciej> | well, warnings are for developers of the code, not consumers of the code |
| 10:09 | <othermaciej> | I don't care about warnings either when I am just compiling someone else's code |
| 10:12 | <hsivonen> | yeah. bad example |
| 10:13 | <hsivonen> | but too many warning lead to warning fatigue. my Eclipse workspace has 927 warnings |
| 10:13 | <hsivonen> | too many to bother to fix them all |
| 10:13 | <hsivonen> | and too harmless to really care |
| 10:14 | <othermaciej> | the WebKit build system treats warnings as errors so it makes me fix mine as I go |
| 10:14 | <othermaciej> | usually they're not indicative of real bugs, but sometimes they are, often enough to be worth the effort |
| 10:15 | <othermaciej> | (I would consider even one real bug fix for every 20 warnings worth it, when considering the cost of any other form of QA) |
| 10:16 | <othermaciej> | but I know of other projects that turn on lots of warning flags in the build system but never fix the warnings |
| 10:16 | <othermaciej> | sometimes they have a theory that they'll go back and fix them in batches at some later time |
| 10:16 | <othermaciej> | usually that later time does not arrive |
| 10:17 | <othermaciej> | I guess this is a matter of taste, and it's hard to pick one option that lets validators cater to anyone's tastes |
| 10:17 | <othermaciej> | I must admit, the terrible results of omitting alt in screen readers (well, JAWS at least) make me doubt the wisdom of omitting alt in public content, it seems like even the worst imaginable autogenerated alt is better |
| 10:18 | <othermaciej> | alt="" or alt="image here" |
| 10:19 | <hsivonen> | even if I had a zero-tolerance policy for my own code, importing someone else's code is a problem |
| 10:19 | <hsivonen> | a great number of warnings come from someone else's code that wasn't originally developed in Eclipse |
| 10:24 | <othermaciej> | a possible middle ground would be to make noalt allowed but not required when alt isn't specified |
| 10:24 | <Lachy> | it may actually end up being better for the wikipedia and flickr examples in the spec, which are marked up using figure/legend, to just use alt="", since figure already indicates that it's a content image |
| 10:24 | <othermaciej> | and validators could have an optional warning for when neither alt or noalt is specified |
| 10:25 | <othermaciej> | that makes its utility even more marginal though |
| 10:26 | <othermaciej> | perhaps the root of the problem is just that announcing the filename is a very bad heuristic |
| 10:26 | <othermaciej> | perhaps compounded by the fact that reading a long string of digits in a garbage filename with millions, billions and thousands instead of just as digits makes it even more annoying |
| 10:27 | <Lachy> | sure, but in some cases, there's nothing else available. Consider <a href="..."><img src=home.png></a>, it's really not that bad |
| 10:27 | <othermaciej> | D3124597.JPG wouldn't think "3 million" while reading it |
| 10:28 | <Lachy> | it just doesn't work for long numeric, auto-generated file names |
| 10:28 | <othermaciej> | it works well for the kind of filenames that are most likely to occur in cases where useful alt text is more likely to be available |
| 10:30 | <othermaciej> | I guess I'm assuming that hearing "dee three million one hundred twenty-four thousand five hundred ninety-seven dot jay pee gee" is way more irritating than seeing the filename |
| 10:30 | <othermaciej> | especially repeatedly hearing similar ones |
| 10:31 | <othermaciej> | but I could be wrong on that, since I've never tried to seriously use a screen reader |
| 10:38 | <krijnh> | Philip`_, zcorpan: added white-space: pre-wrap; :) |
| 10:40 | <zcorpan> | did it make a difference? |
| 10:40 | <krijnh> | In Opera, yes :) |
| 10:41 | <zcorpan> | ah, there |
| 10:41 | <krijnh> | Hmm, Kestrel has support for :target as well, nice |
| 11:11 | <hendry> | is there some forms stuff for telephone numbers with whatwg?? I assumed there probably was |
| 11:21 | <Dashiva> | I hope not, telephone number validation is a nightmare |
| 11:21 | <Dashiva> | (mostly for the users) |
| 11:23 | <hendry> | i'm tired of crap form validators by web authors |
| 11:23 | krijnh | guilty! |
| 11:27 | <Dashiva> | hendry: The only way to validate a phone number is not to validate it |
| 11:34 | <zcorpan> | hendry: pattern=""? |
| 11:35 | <krijnh> | How can you style the default Opera error message? |
| 11:35 | <zcorpan> | not sure you can |
| 11:36 | <zcorpan> | but you can override it altogether |
| 11:44 | <hendry> | zcorpan: ok. i see web authors struggling to come up with a pattern for telephone numbers. oh well |
| 11:57 | <virtuelv> | oh, I never noticed that :target was in |
| 11:57 | <virtuelv> | means http://virtuelvis.com/gallery/css3/target/interface.html#contact now works in most browsers |
| 11:59 | <krijnh> | virtuelv: you work at Opera ;] |
| 12:00 | <krijnh> | How can you not know about :target |
| 12:00 | <virtuelv> | krijnh: yeah, but my day job isn't exactly centered around CSS |
| 12:00 | <krijnh> | Is there anything else? |
| 12:01 | <krijnh> | :+ |
| 12:01 | <virtuelv> | :) |
| 12:01 | hsivonen | smiles at “Sometimes I go so far as to use quotation marks rather than <q> or <blockquote>. I know, I'm completely out of control.” |
| 12:08 | <Lachy> | it's interesting how some people want to introduce semantics for just about everything, while others want to remove existing and useful semantics like blockquote |
| 12:24 | <virtuelv> | removing blockquote!? |
| 12:25 | <zcorpan> | yes, <div class="quote" cite="..."> makes more sense, apparently |
| 12:29 | <zcorpan> | hmm. wonder if there's a simple way to compare two elements' all properties except namespace prefixes |
| 12:30 | <Lachy> | zcorpan, using DOM APIs? |
| 12:30 | <zcorpan> | with javascript |
| 12:30 | <zcorpan> | yeah |
| 12:31 | <zcorpan> | for the purpose of testing getting innerHTML in XML |
| 12:31 | <zcorpan> | i'll build a particular dom tree, then serialize that with innerHTML, parse the resulting string and compare the result with the original tree |
| 12:32 | <zcorpan> | (for now i'll assume that cdata sections must be serialized as cdata sections) |
| 12:32 | <Lachy> | I think you'll have to write your own function |
| 12:32 | <zcorpan> | yeah |
| 12:35 | <Lachy> | why would you compare everything except namespace prefixes? aren't they preserved? |
| 12:37 | <zcorpan> | "User agents may adjust prefixes and namespace declarations in the serialisation (and indeed might be forced to do so in some cases to obtain namespace-well-formed XML)." |
| 12:37 | <Lachy> | ok |
| 12:38 | <zcorpan> | e.g., if you have an attribute in a namespace but no prefix, you have to come up with a prefix when serializing |
| 12:40 | <Lachy> | I don't understand how people are interpreting header and footer as being presentational? |
| 12:40 | <Dashiva> | Anything that's not a div or span is presentational |
| 12:41 | <Lachy> | headers and footers are common features in documents. It's what common word processing software calls them, it's what a significant portion of authors are calling them |
| 12:41 | <Dashiva> | Joke aside, I'd guess they consider having default placement as presentation |
| 12:42 | <Dashiva> | Cf. the footer { position: absolute; top: 0; } example on the list |
| 12:42 | <Lachy> | http://en.wikipedia.org/wiki/Page_header http://en.wikipedia.org/wiki/Page_footer |
| 12:44 | <zcorpan> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010686.html |
| 12:44 | <Lachy> | yeah, but so what? Just because their names are somewhat derived from their presentation doesn't make them presentation |
| 12:45 | <virtuelv> | zcorpan: dropping blockquote sounds more than a little over-the-top |
| 12:45 | <zcorpan> | virtuelv: indeed |
| 12:47 | <Dashiva> | I've been expecting some interaction between the "semantics for semantics' sake" people and the "we don't need no stinkin' new elements" people, but so far there's been little |
| 12:50 | <Lachy> | the people that think "semantics for the sake of semantics" is a good idea, clearly don't understand what we mean by it |
| 12:50 | <Lachy> | they say it's a good idea, and then back it up with examples illustrating semantics that fulfill some use case (though the use case isn't always very strong) |
| 12:51 | <Dashiva> | Yeah, we still have a long way to go in establishing a shared vocabulary |
| 12:52 | <Lachy> | for those people reading IRC logs who don't understand it: semantics for the sake of semantics means the introducing semantics that have no use case at all. Basically a talisman for semanitc purists |
| 12:55 | zcorpan | waves to log readers :) |
| 12:56 | <Dashiva> | The <sentence> suggestion made me think... <sentence><word role="pronoun">I</word><whitespace /></word>agree</word></sentence> |
| 12:56 | <hsivonen> | http://stevenclark.com.au/2007/09/08/the-solution-is-a-html-5-apathetic-doctype |
| 12:57 | <zcorpan> | http://youtube.com/watch?v=dPHtKarae2Q -- log! |
| 12:58 | <Dashiva> | Makes me wonder why anyone would rather read logs on irc than within the comfort of their own irc client |
| 12:58 | <Dashiva> | *on the web |
| 13:01 | <Lachy> | some people may find the temptation to chat all day too distracting to do any work |
| 13:05 | <Lachy> | krijnh, a cool feature for the irc logs would be to list the 20 or so most recent URIs posted in a nice convenient list, so that it's easier to find the interesting ones again later |
| 13:13 | <krijnh> | Lachy: good idea |
| 13:13 | <krijnh> | Lachy: where? :) |
| 13:14 | <krijnh> | And only the last x URIs or an archive? |
| 13:14 | <krijnh> | Can also make a checkbox at the top of the log; "only show lines with URIs" |
| 13:14 | <Lachy> | make it a monthly archive |
| 13:15 | <takkaria> | # |
| 13:15 | <Lachy> | should you do it per channel, or combine them all? |
| 13:16 | <krijnh> | What I should do, is work right now :) |
| 13:16 | <Lachy> | probably better to combine them and then include the channel name and a link to the comment it came from |
| 13:16 | <Lachy> | what? this is work! |
| 13:16 | <Lachy> | :-) |
| 13:16 | <krijnh> | Hehe :) |
| 13:17 | <Lachy> | no worries, there's no rush. let me know when it's done |
| 13:17 | <krijnh> | I think you'll notice when it's done :) |
| 13:17 | <Lachy> | maybe, but I don't check the logs every day |
| 13:17 | <krijnh> | What?! |
| 13:18 | <Lachy> | sorry, I cheat on your logs by reading them from my own client sometimes :-( |
| 13:19 | <krijnh> | Well thanks for ruining my dreams.. |
| 13:19 | <krijnh> | Go ahead and remove alt as well ;] |
| 13:22 | <Lachy> | hey, is there any progress on mirroring the logs on w3.org? |
| 13:22 | <krijnh> | Yeah |
| 13:23 | <krijnh> | "So for now :) I think we can continue like this." |
| 13:23 | <krijnh> | That's progress :) |
| 13:23 | <Lachy> | ok, so the idea has been dropped? |
| 13:24 | <krijnh> | Yeah |
| 13:24 | <Lachy> | ok |
| 13:24 | <krijnh> | Told Karl I wasn't planning to take down my domain/server |
| 13:24 | <krijnh> | And if I did, I would hand over all logs and stuff to them |
| 13:25 | <krijnh> | And would make sure I'd redirect everything properly |
| 13:25 | <Lachy> | ok |
| 13:34 | <hsivonen> | krijnh: RFE for the IRC logs: it would be useful to have classes for people who say stuff on IRC and for people to whon stuff is being said |
| 13:34 | <krijnh> | Come again? |
| 13:34 | <hsivonen> | like the above would have class='auth-hsivonen re-krijnh' or somethig |
| 13:34 | <krijnh> | Ah |
| 13:34 | <krijnh> | That'd be cool |
| 13:35 | <krijnh> | Combined with user stylesheets you mean? |
| 13:35 | <hsivonen> | krijnh: yes |
| 13:37 | <zcorpan> | custom attributes! _author="hsivonen" _re="krijn" |
| 13:38 | <krijnh> | If anybody can hand me the regex stuff for that :) |
| 13:38 | <krijnh> | PHP, $line is the entire line |
| 13:39 | <krijnh> | <?php foreach ($lines as $number => $line) { ?> |
| 13:39 | <krijnh> | <li id="l-<?php echo $number + 1; ?>"<?php if (in_array($number + 1, $flaggedLines)) { echo ' class="flagged"'; } ?>><a href="#l-<?php echo $number + 1; ?>">#</a> <?php echo rtrim($line); ?> <span> </span></li> |
| 13:39 | <krijnh> | <?php } ?> |
| 13:39 | <krijnh> | That's what I'm currently using :) |
| 13:39 | <zcorpan> | hold on |
| 13:40 | <krijnh> | ($line is htmlspecialchar()'ed btw) |
| 13:42 | <zcorpan> | it would be simpler to fetch the relevant bits before htmlspecialchar() :) |
| 13:42 | <krijnh> | Yeah :) |
| 13:42 | <zcorpan> | is that possible= |
| 13:42 | <zcorpan> | ? |
| 13:42 | <krijnh> | Now I just read in the entire file |
| 13:42 | <krijnh> | And htmlspecialchar() that |
| 13:43 | <krijnh> | But it's PHP, so totally flexible ;] |
| 13:43 | <zcorpan> | can't you htmlspecialchar() at the end, after splitting lines? |
| 13:43 | <krijnh> | Sure |
| 13:43 | <zcorpan> | ok |
| 13:44 | <krijnh> | You want the entire code? |
| 13:44 | <zcorpan> | no |
| 13:44 | <krijnh> | oki |
| 13:44 | <krijnh> | Ow wait |
| 13:44 | <krijnh> | I htmlspecialchars() before adding <a> :) |
| 13:44 | <krijnh> | That's why |
| 13:57 | krijnh | is waiting like http://youtube.com/watch?v=TTwgNhX4BSo ;p |
| 14:01 | <krijnh> | Lachy did a better job presenting himself on Youtube |
| 14:03 | <zcorpan> | sorry, got distracted :) |
| 14:03 | <krijnh> | Np :) |
| 14:04 | <krijnh> | It's not like you get payed to work on HTML5 |
| 14:04 | <krijnh> | Ow, wait ;) |
| 14:06 | <zcorpan> | ereg('/<([^>]+)> ([^ ]+(?:\:|,))?/', $line, $regs); |
| 14:06 | <zcorpan> | $author = $regs[1]; |
| 14:07 | <zcorpan> | $re = $regs[2]; |
| 14:07 | <zcorpan> | not tested |
| 14:07 | Lachy | wonders if that german kid was a set up? Why would someone film themselves freaking out and then post it on youtube? |
| 14:12 | <Lachy> | you'd have to process the $author and $re to handle special characters that can't be used in class="" (if any) and you might want to treat names ending with underscores as equivalent to those without |
| 14:13 | <gsnedders> | zcorpan: ereg is being removed by default from PHP6 |
| 14:13 | <zcorpan> | gsnedders: ok. what is to be used instead? |
| 14:13 | <gsnedders> | zcorpan: pcre |
| 14:13 | <gsnedders> | zcorpan: which is installed by default since PHP 4.1, IIRC |
| 14:14 | <Lachy> | what's the difference between the pcre and ereg? |
| 14:14 | <gsnedders> | typical PHP attitude to backwards compat |
| 14:14 | <gsnedders> | Lachy: ereg is POSIX regex, PCRE is perl-compat |
| 14:15 | <Lachy> | yeah, I knew that much, but do they use differnet reg ex syntax? |
| 14:15 | <zcorpan> | ereg is presentational, pcre is semantic |
| 14:15 | zcorpan | hides |
| 14:16 | zcorpan | would be surprised if his suggested regex would actually work, he usually gets something wrong |
| 14:16 | <krijnh> | :) |
| 14:17 | <gsnedders> | zcorpan: what are we trying to do? |
| 14:17 | <zcorpan> | extract author and re |
| 14:17 | <zcorpan> | from $line |
| 14:17 | <krijnh> | gsnedders: extracting hsivonen and krijnh from '[14:43] <hsivonen> krijnh: yes' |
| 14:17 | <Lachy> | gsnedders, see the last messages from hsivonen |
| 14:17 | <gsnedders> | Lachy: POSIX allows things like [[:digit:]], whereas in PCRE you'd need to use [0-9] |
| 14:19 | <zcorpan> | krijnh: the regexp (if it works at all) will only work with "[14:43] <hsivonen> krijnh: yes" |
| 14:19 | <krijnh> | zcorpan: Yeah, I know |
| 14:21 | <krijnh> | Will fix it tomorrow |
| 14:21 | <krijnh> | Real work now :) |
| 14:22 | <gsnedders> | preg_match('/<([^)]*)> (\S*)[:,]/', $line, $match); |
| 14:22 | <gsnedders> | $author = $match[1]; |
| 14:22 | <gsnedders> | $to = $match[2]; |
| 14:22 | <gsnedders> | preg_match('/<([^>]*)> (\S*)[:,]/', $line, $match); even |
| 14:23 | <krijnh> | (and now with < and > ;> ) |
| 14:23 | <gsnedders> | well, just replace them verbatim |
| 14:25 | <gsnedders> | bbl |
| 14:32 | <zcorpan> | that looks better than mine :) |
| 14:32 | <krijnh> | Only matches lines with both in it though :) |
| 14:32 | <krijnh> | Splitting them works |
| 14:36 | <zcorpan> | /<([^>]*)> (?:(\S*)[:,])?/ |
| 14:36 | <zcorpan> | should work |
| 14:37 | <krijnh> | <li id="l-598" _a="zcorpan"><a href="#l-598">#</a> [15:44] <zcorpan> should work <span> </span></li> |
| 14:37 | <krijnh> | \o/ |
| 14:37 | <zcorpan> | perhaps \S+ instead of \S* also |
| 14:37 | <krijnh> | Including the tbe bugs :] |
| 14:38 | <krijnh> | <li id="l-597" _a="zcorpan> /<([^>]*)"><a href="#l-597">#</a> [15:44] <zcorpan> /<([^>]*)> (?:(\S*)[:,])?/ <span> </span></li> |
| 14:38 | <krijnh> | Bah |
| 14:38 | <krijnh> | preg_match('/<(.*)>/U', $line, $match); |
| 14:38 | <krijnh> | (Ungreedy stuff) |
| 14:40 | <zcorpan> | yeah, you need [^>] to make it not leak outside the <...> |
| 14:40 | <krijnh> | Now in your user stylesheet put something like ol#lines li[_a='me'] { color: #aaa; font-size: 60%; } |
| 14:41 | <zcorpan> | which is why it needs to be done before htmlspecialchars :) |
| 14:41 | <krijnh> | It's okay now, right? |
| 14:42 | <zcorpan> | afaict |
| 14:42 | <krijnh> | Or if you really like yourself: ol#lines li[_a='me'] { font-weight: bold; font-size: 120%; } |
| 14:43 | <krijnh> | Of course :) |
| 14:44 | <Lachy> | krijnh, you could make it easier for us and allow us to log in with our usernames, which then sets a cookie that you can use to generate the appropriate CSS |
| 14:44 | <krijnh> | Sure, sure |
| 14:44 | <krijnh> | ;p |
| 14:44 | <krijnh> | *sigh* |
| 14:45 | <Lachy> | where logging in only requres a name, not a password or anything complicated |
| 14:45 | <krijnh> | Yep |
| 14:45 | <krijnh> | A list of names prolly |
| 14:45 | <zcorpan> | doesn't the "to" work? |
| 14:45 | <krijnh> | Not yet |
| 14:45 | <krijnh> | But thanks for trying! :p |
| 14:46 | <zcorpan> | :) |
| 14:51 | <Lachy> | krijnh, replace /:-?[\)\(]/ with emoticon graphics |
| 14:52 | <Philip`> | <li id="l-442" _a="q"><a href="#l-442">#</a> [13:09] * hsivonen smiles at ?Sometimes I go so far as to use quotation marks rather than <q> or <blockquote>. I know, I'm completely out of control.? <span> </span></li> |
| 14:52 | <Philip`> | ^ that _a="q" shouldn't be there |
| 14:52 | <krijnh> | Lachy: Hush! ;p |
| 14:52 | <krijnh> | Any ideas for styling your own lines? |
| 14:52 | <krijnh> | Philip`: good point |
| 14:53 | <Philip`> | What happens if I write <"style="text-decoration:blink> ? |
| 14:53 | <Lachy> | krijnh, how about checking it into google code so we can all contribute to it instead of making you do all the work? |
| 14:53 | <krijnh> | If a line starts with * foobar _a should be foobar |
| 14:53 | <Philip`> | Uh |
| 14:53 | Philip` | tries <"style="text-decoration:blink> again |
| 14:53 | <Philip`> | Bah, you escape it :-( |
| 14:54 | <zcorpan> | /^.{8}<([^>]*)> (?:(\S+)[:,])?/ |
| 14:55 | <krijnh> | :D |
| 14:55 | <krijnh> | http://krijnhoetmer.nl/irc-logs/ |
| 14:55 | <krijnh> | Everybody |
| 14:55 | <krijnh> | Insert your nicks! |
| 14:55 | <krijnh> | ;] |
| 14:55 | <krijnh> | (comma separated doesn't work yet btw) |
| 14:56 | <zcorpan> | lol |
| 14:56 | <krijnh> | :> |
| 14:57 | <krijnh> | Eat that for rapid development, RoR ;p |
| 14:57 | <krijnh> | Anyway, styling for your own lines? |
| 14:57 | <zcorpan> | font-weight:bold ? |
| 14:57 | <Lachy> | yeah, bold would be better than a colour |
| 14:58 | <krijnh> | Refresh |
| 14:58 | <krijnh> | Horrible ;\ |
| 14:58 | <Philip`> | krijnh: What if I have a different name on each channel? :-) |
| 14:58 | <krijnh> | Philip`: comma separated list |
| 14:58 | <Lachy> | oh, I didn't realise you put blink in there (I have it disabled, so I didn't notice) |
| 14:58 | <krijnh> | Philip`: but not yet :) don't want to spoil it this quick |
| 14:59 | <zcorpan> | krijnh: can you have font-family:monospace so i can get my preferred monospace font? :) |
| 14:59 | <krijnh> | Done |
| 14:59 | <zcorpan> | thanks |
| 15:00 | <krijnh> | I don't like the boldish stuff |
| 15:00 | <Lachy> | hmm. bold doesn't work too well with monospace fonts |
| 15:00 | <krijnh> | Nope |
| 15:01 | <zcorpan> | works good with the font i use :) |
| 15:01 | <krijnh> | I guess it's a personal preference |
| 15:01 | <krijnh> | My lines don't make sense |
| 15:01 | <krijnh> | So I like them whiped out |
| 15:01 | <krijnh> | :p |
| 15:01 | <Lachy> | background: lime; isn't too bad |
| 15:02 | <krijnh> | If you like Spice Girls it isn't |
| 15:02 | <krijnh> | (or testcases) |
| 15:02 | <zcorpan> | a left thick border? |
| 15:03 | <Lachy> | background: deepskyblue; ? |
| 15:03 | krijnh | evil |
| 15:03 | <zcorpan> | mediumspringgreen |
| 15:04 | <Lachy> | oh, nice |
| 15:04 | <krijnh> | Anybody else want their own colors? :P |
| 15:04 | <Lachy> | add a colour selector |
| 15:04 | <krijnh> | I should integrate this with myspace |
| 15:04 | <Lachy> | let us pick our own! |
| 15:05 | zcorpan | needs to do actual work now |
| 15:05 | <krijnh> | Same here |
| 15:05 | <krijnh> | Done playing for today :) |
| 15:07 | <krijnh> | Philip`: remind me of the bugs if I forget to do anything about them ;] |
| 15:07 | <virtuelv> | hm. does khtml support "opacity" now, or is it just -khtml-opacity? |
| 15:07 | <virtuelv> | (and webkit?) |
| 15:09 | <Philip`> | krijnh: Don't expect me to ever remember anything :-p |
| 15:10 | <krijnh> | :) |
| 15:10 | <Philip`> | Or, rather, expect me to remember things, but don't expect any specific thing to be remembered by me, since it's pretty much random whether I remember or forget a particular thing |
| 15:30 | <hsivonen> | krijnh: thank you. |
| 15:35 | <krijnh> | hsivonen: np |
| 15:56 | <zcorpan> | yay! |
| 15:56 | <zcorpan> | i think my function compareNodes actually works |
| 15:56 | <zcorpan> | on first try (after fixing trivial syntax mistakes) |
| 16:01 | <zcorpan> | http://simon.html5.org/test/html/serializing/support/test.xht |
| 16:01 | <zcorpan> | the demo doesn't work in opera though since we don't support getElementsByTagNameNS :( |
| 16:04 | <zcorpan> | oh wait |
| 16:04 | <zcorpan> | we do... i just uploaded the wrong file |
| 16:11 | <Lachy> | zcorpan, it's not clear what this output actually means: [object Text],[object Text],the text nodes' data |
| 16:13 | <zcorpan> | indeed |
| 16:14 | <zcorpan> | it returns the nodes that were different and a text that explains what was different |
| 16:14 | <zcorpan> | if nothing was different it returns the nodes and an empty string |
| 16:15 | <Lachy> | ok |
| 16:15 | <zcorpan> | that demo isn't very useful except for me to see that it works :) |
| 16:32 | <zcorpan> | hmm, didn't get it quite right with namespaced attributes |
| 18:23 | <Philip`> | http://canvex.lazyilluminati.com/misc/shadow/shadowdemo.png / http://canvex.lazyilluminati.com/misc/shadow/shadowdemo.html - did I forget any interesting cases to test? |
| 18:39 | <zcorpan> | http://simon.html5.org/test/html/serializing/002.xht |
| 18:39 | <zcorpan> | phew! |
| 18:40 | <zcorpan> | i really had to jump through hoops to test getting innerHTML (in both html and xml) |
| 18:42 | <zcorpan> | i had to come up with a custom format to express dom trees: http://simon.html5.org/specs/sdf |
| 18:42 | <zcorpan> | write a parser for that format in javascript |
| 18:44 | <zcorpan> | then write the actual tests in that format, and the expected html string (or exception) and expected exception for xml (if any) |
| 18:45 | <zcorpan> | for html, i parse the custom format and build a tree, then serialize it using innerHTML and compare the string with the expected html (or check if an exception was raised) |
| 18:46 | <zcorpan> | for xml, i parse the custom format and build a tree, then serialize it using innerHTML, then parse that with an XML parser, then compare the result with the original tree using a function that compares all characteristics of each node *except* namespace declarations and namespace prefixes |
| 18:48 | <Philip`> | zcorpan: http://simon.html5.org/specs/sdf - "It has tree strings ..." |
| 18:49 | <Philip`> | and "respecively" |
| 18:50 | <Philip`> | "U+00A0 LINE FEED" |
| 18:51 | <zcorpan> | fixed, thanks |
| 18:54 | Dashiva | wonders why anyone would consider [[:digit:]] an improvement over [0-9] |
| 18:55 | <Hixie> | in case the range changes |
| 18:56 | <Hixie> | like "PI" is better than 3.14..., in case the value of PI changes |
| 18:56 | <Hixie> | :-P |
| 18:57 | <Philip`> | You might want to include all Unicode digits, and the [...] syntax isn't incredibly great for that |
| 18:59 | <Hixie> | :digit: doesn't include Ud, does it? |
| 18:59 | <Hixie> | i thought it was only 0-9 |
| 19:02 | <Hixie> | er, Nd, i guess |
| 19:02 | <Philip`> | perl -e'for (qr/[0-9]/, qr/[[:digit:]]/, qr/\d/) { print "\x{0b66}" =~ $_ ? 1 : 0 }' |
| 19:02 | <Philip`> | says 011 |
| 19:02 | <Philip`> | since U+0B66 is category Nd |
| 19:03 | <Hixie> | ah |
| 19:03 | <Hixie> | then that answers Dashiva's question |
| 19:03 | <Hixie> | they're not the same :-) |
| 19:03 | <Dashiva> | But if you're matching more than 0-9 you'd obviously use \d |
| 19:04 | <Philip`> | What if you want to match e.g. digits or commas? |
| 19:04 | <Dashiva> | [\d,] |
| 19:04 | <Philip`> | Hmm... |
| 19:05 | <Philip`> | What if you want to match e.g. digits or whitespace? |
| 19:05 | <Philip`> | given that \s is not equivalent to [:space:] |
| 19:05 | <Philip`> | Actually, ignore the digits bit |
| 19:05 | <Philip`> | Actually, ignore all of that |
| 19:06 | <Philip`> | since you could use [\s\ck] instead of [[:space:]] which isn't that bad |
| 19:07 | <Philip`> | and it's irrelevant for the case of [:digit:] vs \d |
| 19:08 | <Philip`> | But [:digit:] wins because it has theoretical purity, being consistent with the other Unicode category matchers |
| 19:12 | <Dashiva> | Semantics for semantics' sake, eh? :P |
| 19:21 | <tndH_> | fwiw, with a recent php/pcre you can do stuff like /\p{Nd}/u |
| 19:25 | <Philip`> | Looks like Perl does that too, but without the /u |
| 19:25 | <Hixie> | i just realised that this e-mail: http://html4all.org/pipermail/list_html4all.org/2007-August/000054.html |
| 19:25 | <Hixie> | was sent the very day before i banned him from the whatwg list for 2 weeks for being unreasonable. |
| 19:28 | <Dashiva> | So while we joke about cabals and conspiracies, they go and form one? |
| 19:28 | <Hixie> | yeah, isn't it awesome? |
| 19:31 | <Dashiva> | I dunno, how come they aren't getting formal complaints against them? :) |
| 19:31 | <Philip`> | I still don't see why they form a secret cabal with a public mailing list |
| 19:44 | <kingryan> | Philip`: for the same reason we formed a secret cabal w/ a public IRC channel |
| 21:38 | <zcorpan> | interesting. |
| 21:38 | <zcorpan> | in opera, setting innerHTML in xml does not raise an exception if the string was malformed |
| 21:39 | <zcorpan> | but with DOMParser() it does |
| 21:39 | <zcorpan> | safari is the exact opposite |
| 21:39 | <zcorpan> | DOMParser() silently passes (it seems to use some sort of liberal xml parser, actually) while innerHTML throws |
| 21:42 | <othermaciej> | DOMParser uses libxml |
| 21:42 | <othermaciej> | however, it might give you an XML error document (parsed up to the first error) instead of failing |
| 21:43 | <zcorpan> | aha |
| 21:43 | <zcorpan> | does it have any characteristics i can look for? |
| 21:46 | <zcorpan> | a <parseerror> element somewhere |
| 21:47 | <zcorpan> | as the first child of the root element even |
| 21:47 | <zcorpan> | ok |
| 21:48 | <Hixie> | kingryan: #whatwg is hardly secret :-) |
| 21:54 | <gsnedders> | Hixie: shhhhh |
| 21:54 | <gsnedders> | Hixie: don't tell anyone! |
| 22:14 | <zcorpan> | er, make that <parsererror> |
| 22:29 | <zcorpan> | so in webkit, the error page can either have a root element "parsererror", or the root element's first child is a "parser error", or the root element's first child's first child is a "parser error" |
| 22:29 | <zcorpan> | s/parser error/parsererror/ |
| 22:30 | zcorpan | would really prefer an exception instead |
| 22:30 | <zcorpan> | when dealing with DOMParser() |
| 22:33 | <zcorpan> | re done event, isn't it possible to do onload = onerror = onabort = function() { ... } ? |
| 22:34 | <zcorpan> | (which is still less nice than ondone = function() { ... } i guess) |
| 22:44 | <zcorpan> | Hixie: when serializing innerHTML in xml, and the element is in no namespace, does xmlns="" need to be specified? |
| 22:45 | <zcorpan> | e.g., take this document: <h:p xmlns:h='http://www.w3.org/1999/xhtml'><x/></h:p>; |
| 22:45 | <zcorpan> | what is the P's innerHTML? |
| 22:45 | <zcorpan> | is <x/> ok, or does it need to be <x xmlns=""/> |
| 22:48 | <zcorpan> | since setting innerHTML will imply a default namespace, i think the latter |
| 22:50 | zcorpan | thinks the spec needs to be specific about the namespace declarations and prefixes |
