| 01:32 | <aboodman> | question on MessagePorts: why do they have an ownerWindow? |
| 01:32 | <aboodman> | it seems weird that you can reach ownerWindow.openDatabase, for example |
| 01:37 | <Hixie> | aboodman: ownerWindow is always the Window in which they are found, so you can always get to the Window anyway |
| 01:38 | <Hixie> | i suppose it doesn't have to be made visible to the interface |
| 01:38 | <aboodman> | but if I pass a MessagePort through to some other context, what will that context see for port.ownerWindow ? |
| 01:38 | <aboodman> | what if it is cross-origin? |
| 01:38 | <Hixie> | the ownerWindow will change to the new context |
| 01:39 | <aboodman> | oh, i didn't get that part. |
| 01:39 | <Hixie> | it's the owner of the port at that time, not the original owner or the creator |
| 01:39 | <Hixie> | yeah |
| 01:39 | <aboodman> | what is the point of this property? |
| 01:39 | <Hixie> | i need to write an intro section |
| 01:39 | <Hixie> | i'm not sure why i made it a property |
| 01:39 | <Hixie> | the concept is needed for various aspects of how the ports work |
| 01:39 | <Hixie> | i don't think we need to actually expose it |
| 01:39 | <aboodman> | right |
| 01:39 | <aboodman> | ok, thanks |
| 01:40 | <Hixie> | if you want it removed, send mail and i'll look at why i put it there in the first place |
| 01:40 | <aboodman> | ok |
| 01:40 | <Hixie> | right now i'm swamped with dealing with all kinds of whining people |
| 01:40 | <aboodman> | ok, can you talk about another aspect of this spec now? |
| 01:40 | <Hixie> | sure |
| 01:40 | <Hixie> | i can talk abotu anything :-) |
| 01:40 | <aboodman> | (i will send mail about it too, but i just love this low latency communication :)) |
| 01:41 | <aboodman> | ok, web workers, processing model, step 10 |
| 01:41 | <aboodman> | it says that scripts running in the worker will get suspended when the worker is no longer an active needed worker |
| 01:42 | <Hixie> | right |
| 01:43 | <aboodman> | so this means that if you say: createWorker("foo.js"), but don't hold a reference to the returned port, foo.js may get paused at any random point |
| 01:43 | <aboodman> | (whenever gc happens) |
| 01:44 | <aboodman> | let me back up... what is that step for? |
| 01:44 | <Hixie> | if you don't hold on to the reference, then step 9 will soon set closing to true |
| 01:45 | <Hixie> | and step 10 won't trigger, since it only triggers when closing = false |
| 01:45 | <Hixie> | and so the worker will gracefully shutdown |
| 01:45 | <Hixie> | the step is intened to pause workers when someone hits the back button and the browser doesn't throw the document away |
| 01:45 | <Hixie> | e.g. firefox's bfcache |
| 01:46 | <aboodman> | I see. |
| 01:46 | <aboodman> | the ports can become inactive separately from being gc'd, i forgota bout that |
| 01:46 | <Hixie> | yeah |
| 01:47 | <Hixie> | if they try to gc, step 10 doesn't kick in, because step 9 does and step 10 only kicks in when 9 doesn't |
| 02:07 | <jcranmer> | Hixie: you should update the implementation status for FF and audio |
| 02:08 | <Hixie> | you can do so too :-) |
| 02:08 | <Hixie> | what should it say? |
| 02:08 | <jcranmer> | experimental support |
| 02:08 | <Hixie> | (alt-double-click on a section to edit the status) |
| 02:09 | <Hixie> | ok, will change |
| 02:09 | <jcranmer> | alt-double click where? |
| 02:09 | <Hixie> | anywhere in a section |
| 02:10 | <jcranmer> | oh, I have to login first, I presume? |
| 02:11 | <Hixie> | yeah |
| 02:11 | <Hixie> | if you've ever sent feedback, you'll have a login name and password |
| 02:11 | <Hixie> | login name is the e-mail you used to send feedback |
| 02:11 | <Hixie> | password will be sent to that address |
| 02:11 | <jcranmer> | and it would help if my WM didn't use alt to handle window stuff... |
| 02:12 | <Hixie> | heh |
| 02:13 | jcranmer | is surprised he beat roc to an example of <audio> in a blog |
| 02:16 | <Hixie> | feel free to add urls to examples and demos in the spec too |
| 02:20 | <takkaria> | I was going to go and update bits of the annotations but I had the same alt- being used for my window manager -problem |
| 02:23 | <Hixie> | heh |
| 02:24 | jcranmer | gets lazy and solves the problem the easy way |
| 02:24 | <Hixie> | you can press ctrl+alt at the same time i think |
| 02:24 | <Hixie> | if that helps |
| 02:25 | <jcranmer> | ah, that works |
| 02:25 | <jcranmer> | no need to do my workaround: edit host files to point to localhost and then do apache rewriting to change the JS file to use something else |
| 02:29 | <Hixie> | heh |
| 02:30 | <Hixie> | that was your easy way? :-) |
| 02:30 | <jcranmer> | easiest way I could think of to edit the source of another page |
| 02:30 | <Hixie> | heh |
| 02:31 | <Hixie> | i wonder how a script on whatwg.org can work out what revision it is |
| 02:31 | <jcranmer> | I have a few rewrites that redirect unstable.elemental.com to my localhost |
| 02:36 | <jcranmer> | what makes a boolean attribute false? |
| 02:36 | <jcranmer> | it says it's presence makes it true |
| 02:36 | <jcranmer> | but if it's present, it's value is either empty of the name of the attribute itself |
| 02:36 | <jcranmer> | so what would attr="false" return? |
| 02:36 | <jcranmer> | s/return/reflect/ |
| 02:37 | <takkaria> | I believe the thing that makes a boolean attribute false is if it is not set |
| 02:39 | <jcranmer> | I just want to have confirmation of this before I mark a bug as INVA |
| 02:40 | <aboodman> | Hixie: It seems like right now workers shut down whenever there is no non-gc'd port that refers to them. Even if they have script in progress or things like XHR and timers pending. Is this right? |
| 02:41 | <Hixie> | aboodman: they set closing to true and run through the closing steps first, so it's gracefull-ish, but yes, fundamentally they're just killed when their owners go away |
| 02:41 | <Hixie> | jcranmer: its absence |
| 02:42 | <aboodman> | right but it is non-deterministic |
| 02:42 | <aboodman> | if the UA doesn't GC then the worker might not shut down |
| 02:42 | <Hixie> | yeah, i wasn't sure what to do abotu that |
| 02:43 | <Hixie> | i mean, it's non-deterministic anyway, since it's on another thread |
| 02:43 | <aboodman> | I think that workers should stay alive as long as: |
| 02:43 | <aboodman> | they have script running, they have messages queued for them, they have http requests outstanding, or they have timers ounstanding |
| 02:44 | <aboodman> | that would eliminate a lot of hard to understand bugs, when workers sometimes go away and sometimes don't with the same code |
| 02:44 | <Hixie> | well it has to be more than that |
| 02:45 | <Hixie> | otherwise any random page can just start a worker with a timer and it'll never go away |
| 02:45 | <aboodman> | navigation would of course always either nuke or suspend workers |
| 02:45 | <aboodman> | whatever is appropriate for the UA |
| 02:46 | <Hixie> | how is that not non-deterministic? |
| 02:46 | <Hixie> | when you navigate, the worker now has an indeterminate amount of processing time left |
| 02:46 | <aboodman> | if i'm a developer and i write some code that uses workers, but i make a mistake and don't hold the port that comes back |
| 02:46 | <aboodman> | the code inside that worker will stop running at some random point |
| 02:46 | <aboodman> | even without navigating the page |
| 02:46 | <othermaciej_> | workers should stay alive at least so long as someone can message them, even if no messages are queued |
| 02:47 | <othermaciej> | otherwise, any global data set inside the worker could be lost on a race condition of message delivery |
| 02:47 | <aboodman> | othermaciej_: that is in the spec now i think |
| 02:47 | <othermaciej> | yeah, I'm just disagreeing with your "as long as" above, at least as an exhaustive list |
| 02:47 | <Hixie> | aboodman: it doesn't stop running at a random point |
| 02:47 | <aboodman> | right, sorry, I forgot about "someone can message them" |
| 02:47 | <Hixie> | aboodman: it runs to completion |
| 02:47 | <othermaciej> | and I am not sure "someone can message them" can be determined short of GC |
| 02:48 | <othermaciej> | unless there is an explicit way to close a message port I suppose |
| 02:48 | <Hixie> | there is, but i doubt many people will use it, and i certainly don't think we should rely on them doing so |
| 02:49 | <aboodman> | does "run to completion" means that the current event that is being processed finishes, or does it mean that all queued events finish being processed |
| 02:49 | <othermaciej> | yeah, you can't realy on it |
| 02:50 | <Hixie> | aboodman: all queued events get processed (but no new events can be queued once closing is true) |
| 02:50 | <aboodman> | othermaciej: I agree that you can't determine "someone can message them" short of a GC, but I"m just saying that that alone should not determine the worker's lifetime. |
| 02:51 | <aboodman> | Hixie: ok, but httprequests still may or may not happen, right? |
| 02:51 | <aboodman> | same with timers I suppose |
| 02:51 | <othermaciej> | aboodman: I think a message with queued messages or pending timers or pending I/O should continue even if no one can (currently) message it |
| 02:51 | <othermaciej> | aboodman: I don't see how you would do it without either counting on GC, or explicit close |
| 02:51 | <Hixie> | if an xml http request is outstanding, or if there is a repeating interval or an outstanding timer waiting, those are discarded, yes |
| 02:51 | <Hixie> | because otherwise you could use that to stay alive forever |
| 02:52 | <othermaciej> | I am assuming here that the message port for the thread is a GC object and anyone who can reach that object can send a message |
| 02:52 | <Hixie> | othermaciej: yes |
| 02:52 | <othermaciej> | Hixie: I know that is true in the current spec, what I mean is I am assuming it even for hypothetical designs that tried to make shutdown time not depend on GC |
| 02:53 | <aboodman> | othermaciej: I agree with you, but I don't think the spec reflects this |
| 02:54 | <Hixie> | othermaciej: ah ok |
| 02:54 | <othermaciej> | "fire and forget" threads should be allowed IMO, if they are doing I/O or something |
| 02:55 | <aboodman> | Hixie: are you worried specifically about named workers staying alive forever? Because I don't see the problem with anonymous ones doing that. They will go away at page unload. |
| 02:55 | <Hixie> | right now the mechanism for them going away at page unload is the same mechanism as them going away any other time |
| 02:55 | <Hixie> | i suppose we could have a new mechanism |
| 02:55 | <Hixie> | that is different for that case |
| 02:56 | <aboodman> | it doesn't have to be ... unload could just be defined to nuke all (anonymous) workers |
| 02:56 | <Hixie> | that won't work |
| 02:56 | <Hixie> | workers can be created by one window and passed off to another |
| 02:57 | <aboodman> | Right. I didn't realize that you intended for those to stay alive. |
| 02:57 | <aboodman> | past their owning window closing. |
| 02:57 | <Hixie> | they are still "active" and "needed", in that you can still send messages to them |
| 02:57 | <Hixie> | i think it'd be confusing if they had a lifetime bounded by whatever random iframe or worker created them |
| 02:58 | <Hixie> | you want to be able to have a worker spawn off new workers to service requests for gadgets or whatever |
| 02:58 | <Hixie> | and have those live independent of hte original factory worker |
| 02:58 | <othermaciej> | I think maybe there should be different mechanisms for termination on navigation vs otherwise |
| 02:58 | <othermaciej> | though unsure of the detauls |
| 02:58 | <othermaciej> | *details |
| 02:58 | <aboodman> | I see the problem. I was thinking of anonymous workers as more firmly attached to a page. |
| 02:58 | <othermaciej> | for the scope of a particular page I think it should be possible to make a thread that will periodically message you but that you don't care to message ever |
| 02:58 | <othermaciej> | for instance |
| 02:59 | <othermaciej> | but such a thread should not (under ordinary circumstances) survive a page navigation |
| 02:59 | <Hixie> | othermaciej: hm, right now to do that you'd have to keep a reference in the page |
| 02:59 | <Hixie> | iirc |
| 02:59 | <aboodman> | othermaciej: if it can message you, you have a port for it, so it will stay alive. |
| 02:59 | <Hixie> | not if you set up a handler for the port and then drop it all on the floor |
| 03:00 | <othermaciej> | oh I see, the ports are all bidirectional |
| 03:00 | <Hixie> | oh wait |
| 03:00 | <Hixie> | no |
| 03:00 | <Hixie> | othermaciej: yes |
| 03:00 | <Hixie> | the other port itself will prevent the port from being GC'ed |
| 03:00 | <Hixie> | so what you describe will work |
| 03:00 | <aboodman> | right. |
| 03:00 | <othermaciej> | I forgot about that (though it leads to something else in the spec I don't like, the fact that ports are killed on transfer) |
| 03:01 | <othermaciej> | ports that are endpoints of the same pipe protect each other? |
| 03:01 | <Hixie> | yeah |
| 03:01 | <Hixie> | (s/pipe/channel/) |
| 03:01 | <othermaciej> | what about a completely fire-and-forget thread, where you ask it to do some I/O but no further messaging is expected either way? |
| 03:01 | <aboodman> | but you couldn't, for example, set up a worker that would synchronize a database with the network but never message the creator. |
| 03:01 | <aboodman> | it would seem to work for a little while, but it would go away after awhile. |
| 03:02 | <Hixie> | othermaciej: right now that thread will die before it gets its onreadystatechange, assuming that it uses async IO |
| 03:02 | <Hixie> | aboodman: yeah... |
| 03:02 | <Hixie> | not sure how to handle these two cases |
| 03:03 | <othermaciej> | it seems like a potentially useful use case |
| 03:03 | <Hixie> | i agree it'd be good to handle them |
| 03:03 | <aboodman> | i'm less concerned about the use case than it failing in weird ways |
| 03:03 | <othermaciej> | you could let self-effected liveness criteria not count at page navigation time or something |
| 03:04 | <Hixie> | actually... |
| 03:04 | Hixie | looks at the spec |
| 03:05 | <Hixie> | so... |
| 03:05 | <Hixie> | what we could do is add an implicit link from any worker to whoever created it |
| 03:06 | <Hixie> | so that it won't ever get killed if whoever created it is still there, so long as it has any outstanding timers, intervals, database callbacks, or xmlhttp request callbacks pending |
| 03:09 | <aboodman> | so the creator doesn't reference it in the same way that a port does... it is only used in the case where there are no live ports |
| 03:10 | <aboodman> | if there are no live ports, but there is outstanding IO or timers, and the creator is still there, then it keeps running |
| 03:11 | <Hixie> | right |
| 03:11 | <Hixie> | though that will make debugging a bitch |
| 03:11 | <Hixie> | "why is that worker still running? how do i disable it? |
| 03:11 | <Hixie> | " |
| 03:11 | <Hixie> | just because it happens to have setInterval(function () {}, 100); |
| 03:12 | <aboodman> | hm, yeah. weird. i'll think about it. |
| 03:13 | <othermaciej> | a number of DOM-related objects have "live while some message is pending, even if no one kept a reference" semantics |
| 03:13 | <othermaciej> | for instance this is true of Image and XMLHttpRequest |
| 03:13 | <othermaciej> | workers of course have a much richer way of making themselves have a pending action |
| 03:13 | <aboodman> | yeah the only thing that is weird with workers is that their lifespans can be longer than a page |
| 03:14 | <othermaciej> | that is true of Image and XMLHttpRequest too |
| 03:14 | <Hixie> | yeah |
| 03:15 | <aboodman> | how is it true of image and xhr? |
| 03:15 | <Hixie> | aboodman: feel free to send mail if you come up with some other idea (or even if you don't); i agree that we should do something about this either way |
| 03:15 | <othermaciej> | you can hand one to a different page |
| 03:15 | <aboodman> | wow, I didn't realize that. |
| 03:15 | <othermaciej> | (don't remember what happens if you then navigate the originating page) |
| 03:15 | <othermaciej> | you can pass references to any object in the DOM cross-frame (which amounts to cross-page) |
| 03:15 | <aboodman> | i mean it makes sense you can pass the object to another page, it's just an object |
| 03:16 | <aboodman> | i just never considered what should happen when you do this with an xhr |
| 03:16 | <Hixie> | heh |
| 03:16 | <aboodman> | it would be interesting to know what xhr does when you navigate the originating page |
| 03:18 | <othermaciej> | it may depend on which frame started the load rather than which constructed the object |
| 03:18 | <othermaciej> | not really sure though |
| 03:18 | <aboodman> | i need to run, i'll start a thread with this feedback on the list |
| 03:18 | <aboodman> | thanks both for your time |
| 03:18 | <Hixie> | cool |
| 03:18 | <Hixie> | np |
| 03:18 | <Hixie> | thanks for the feedback! |
| 03:44 | <Hixie> | Lachy: ok, there's a checkbox in the status section now which, if checked, will let you know within 30 seconds of me committing some new revision |
| 06:19 | <Hixie> | aboodman2, othermaciej, it would be useful to have your input on the issues sicking has raised recently, like pushState() and the workers stuff |
| 06:20 | <aboodman2> | you mean the message he just sent, or was there something earlier? |
| 06:20 | <aboodman2> | also, I'm trying to reply, but whatwg.org is not responding :-/. |
| 06:20 | <Hixie> | that one, and the thread on pushState() recently (which i just replied to -- i'll give you a link in a sec) |
| 06:20 | <Hixie> | uh yes the server seems non-responsive wtf |
| 06:21 | <Hixie> | the machine is working fine except apache is on strike |
| 06:21 | <aboodman2> | I didn't understand his comment about pulling in all of navigator and window. I was going to check the proposal again, because I don't remember that being true. |
| 06:22 | <Hixie> | i think he was speaking hypothetically |
| 06:22 | <Hixie> | why is apache not working |
| 06:23 | <othermaciej> | Hixie: I saw the pushState thread |
| 06:23 | <othermaciej> | Hixie: in general it kind of makes sense to require auxiliary data to be stuffed into the URL somehow, since that preserves bookmarkability and shareability of the URL as well as back/forward |
| 06:24 | <othermaciej> | Hixie: but perhaps there are use cases where back/forward is very useful but recording a particular configuration persistently is not, in which case some form of data would make sense |
| 06:24 | <othermaciej> | that's my off-the-cuff opinion |
| 06:24 | <Hixie> | i'm ok with dropping the data part and only using URL |
| 06:25 | <Hixie> | ok seriously wtf is with my server |
| 06:25 | Hixie | reboots it, because, well, what else can he do |
| 06:26 | <aboodman2> | Hixie |
| 06:26 | <aboodman2> | whoa, sorry, new IRC client, unfamiliar controls |
| 06:26 | <Hixie> | aboodman2 |
| 06:26 | <Hixie> | :-) |
| 06:27 | <aboodman2> | Hixie: I havne't looked at the state management spec at all, so I don't think I have much to say about that thread right now. |
| 06:27 | <Hixie> | aboodman2: server's back up |
| 06:27 | <Hixie> | ok |
| 06:27 | <aboodman2> | I'll try and catch up on it, but right now my higher concerns are workers, database, and offline |
| 06:28 | <Hixie> | sure |
| 06:29 | <Hixie> | i'm just curious to get the opinion of other implementors, lest one implementor end up with undue influence |
| 06:29 | <Hixie> | nothing against jonas of course, i have the utmost respect for him |
| 06:42 | <aboodman2> | Hixie: what is the name of the interface that Window and WorkerWindow share? I cannot find it. |
| 06:43 | <aboodman2> | WindowWorker, sorry |
| 06:46 | <aboodman2> | nevermind, found it. |
| 06:48 | <Hixie> | sorry was afk |
| 07:04 | <mcarter> | I don't suppose anyone has any idea what is supposed to happen (if there is a standard) if an HTTP/1.1 XHR response is half over when there is a page navigation. Should it a) shut the connection immediately, or b) wait for the rest of the response (though now irrelevant), and then re-use the connection? |
| 08:55 | <Hixie> | r2000! |
| 09:20 | <Hixie> | i'm starting to think that julian wants me to _require_ that people use URIs, not just allow it |
| 09:20 | <Hixie> | (for class names) |
| 09:20 | <hsivonen> | Hixie: yes |
| 09:21 | <Philip`> | (For class names that are intended to have a shared meaning across multiple sites and tools, I presume) |
| 09:21 | <hsivonen> | the migration of the cc prefix from http://web.resource.org/cc/ to http://creativecommons.org/ns# shows that vocabularies outlive domain bikeshedding |
| 09:22 | <Philip`> | Does anyone use IP addresses in namespace identifiers? |
| 09:22 | <hsivonen> | Philip`: not in the wikimedia dataset |
| 09:23 | <hsivonen> | also, the most common metadata item is utterly pointless: http://purl.org/dc/elements/1.1/ dc format |
| 09:24 | <Philip`> | http://www.google.com/search?q=%22xmlns+http+1..255%22 - oh, they do |
| 09:24 | <hsivonen> | if you are looking for metadata inside an svg file, surely you should be able to infer that the format is SVG |
| 09:24 | <Philip`> | (By the way, why does Google bolden the first two numbers in the IP addresses in the search results?) |
| 09:24 | <hsivonen> | wow |
| 09:26 | <Philip`> | Class names should just be GUIDs |
| 09:31 | <Hixie> | if he wants everyone to use uris, then that seems a bit rude... |
| 09:32 | <hsivonen> | Hixie: if only some people use uris and others use anything, anything may accidentally collide with an URI |
| 09:33 | <Hixie> | yeah, that's likely </sarcasm> |
| 09:34 | <hsivonen> | easy fix: if colon, must be uri |
| 09:38 | <Hixie> | seriously, if he's actually worried that people will invent class names that coincidentally happen to look exactly like URIs in his domain, then he has his priorities wrong |
| 09:39 | <othermaciej> | look, the problem is clear |
| 09:40 | <othermaciej> | we can't let extensions to the Web be limited by a central registry |
| 09:40 | <hsivonen> | othermaciej: including TLDs? |
| 09:40 | <othermaciej> | that is why we must use a mechanism with *two* central registries, one for URI schemes, and one for domain names |
| 09:41 | <othermaciej> | because then it is decentralized |
| 09:56 | <Hixie> | the recent thread on the big-issue markup is surprisingly good at distinguishing people who understand the web and accessibility and those who don't |
| 10:04 | <gDashiva> | hsivonen: About the cc: prefix, are you saying the namespace was changed, but everything just uses cc: and didn't notice, or? |
| 10:22 | <hsivonen> | gDashiva: the prefix was retained. the local part of the vocabulary was retained. the URI changed, breaking processors that process namespaces or RDF correctly |
| 10:23 | <Philip`> | Just set up an HTTP redirect at the old URI, and it should all be fine |
| 10:23 | <hsivonen> | hah |
| 10:24 | <Philip`> | Hixie: "If it is no a number" |
| 10:24 | <Hixie> | fixed |
| 10:24 | <Hixie> | hsivonen: is v.nu expected to be down? |
| 10:25 | <hsivonen> | Hixie: no |
| 10:25 | <Hixie> | it's been returning 503 for a few hours now |
| 10:25 | <Hixie> | html5.validator.nu specifically |
| 10:25 | <Hixie> | (trying to validate the spec) |
| 10:26 | <hsivonen> | I'll move to a place where I can sit down to fix. |
| 10:26 | <Hixie> | btw for those of you who weren't around earlier, there is now a magic checkbox in the SotD section of the whatwg draft |
| 10:26 | <Hixie> | and we crossed the 2000 revision mark |
| 10:26 | <gDashiva> | magic checkbox, wow |
| 10:28 | <Philip`> | Sadly revision 2000 was just shuffling some text around and seemingly didn't introduce any new errors, so I can't complain about an R2K bug |
| 10:28 | <Hixie> | heh |
| 10:29 | <gDashiva> | Maybe he modified the commit-watchers mail |
| 10:29 | <hsivonen> | Hixie: it's back up now |
| 10:29 | <hsivonen> | I really need to get that SMS thing in place |
| 10:30 | <hsivonen> | Hixie: thanks for the heads up |
| 10:30 | <Hixie> | np, sorry for not telling you earlier |
| 10:31 | <Hixie> | i can have my system e-mail you if it notices a problem if you like |
| 10:32 | <hsivonen> | Hixie: email doesn't reach me when there's a situation that I'm not otherwise babysittng the server :-( |
| 10:32 | <Hixie> | k |
| 10:38 | <Lachy> | that distributed extensibility thread is getting really annoying. It seems to be taken for granted that a) clashes are inevitable and b) it causes big problems when they occur, without actually explaining what the problem is when 2 distinct sites use common class names for different purposes, intended for processing by their own individual tools |
| 10:38 | <Hixie> | yes it's especially annoying given that both a and b are flase |
| 10:38 | <Hixie> | false |
| 10:39 | <Lachy> | if their extensions are intended for use outside their own domain, then such extensions need community involvment. Otherwise, it really makes no difference |
| 10:39 | <Hixie> | what should happen to transparency when someone uses toDateURL() with a non-transparency-supporting image type? |
| 10:39 | <Hixie> | Lachy: feel free to take over from me here, i'm quite ready to move on to more productive things |
| 10:40 | <Lachy> | nah, I've avoided contributing to the whole thread on the list in the hope that it would die out on its own |
| 10:40 | <gDashiva> | Clearly hash functions would never work on the internet |
| 10:41 | <Lachy> | it should either be converted to the <canvas> element's background colour (if any), or some default colour like white |
| 10:41 | <Philip`> | Canvases rarely have a background-color so it seems weird and unexpected to depend on that |
| 10:41 | <Philip`> | s/a/a non-transparent/ |
| 10:42 | <Hixie> | not to mention off-DOM canvasaes |
| 10:42 | <Hixie> | or canvii |
| 10:42 | <Lachy> | then in those cases, they would use the default colour |
| 10:43 | <Hixie> | i'm saying it should just drop the alpha channel |
| 10:43 | <Hixie> | which basically means using black |
| 10:43 | <Philip`> | It seems simplest to always effectively composite onto a solid black or white background |
| 10:43 | <Philip`> | and if people want some other background then they can draw it manually |
| 10:43 | <Philip`> | "drop the alpha channel" may confuse people who are using premultiplied alpha representations |
| 10:44 | <Hixie> | + <p>For image types that do not support all the channels (in particular, |
| 10:44 | <Hixie> | + that do not support an alpha channel) the unsupported channels must be |
| 10:44 | <Hixie> | + ignored when creating the image. |
| 10:44 | <Hixie> | what should i say instead? |
| 10:44 | <Philip`> | Why try to cover the non-existent case where an image format is missing support for the R/G/B channels? |
| 10:45 | <Philip`> | Well, not really non-existent, since some greyscale formats exist, but then you'd want to do something cleverer rather than just dropping all the colour channels |
| 10:45 | <Lachy> | so if someone set the colour to rgba(255, 0, 0, 0), then dropping the alpha channel would make it go red? |
| 10:45 | <Hixie> | if someone set the colour to rgba(255, 0, 0, 0), it would probably be stored as 0,0,0,0 |
| 10:45 | <Lachy> | ok |
| 10:46 | <Philip`> | Oh, that sounds confusing |
| 10:46 | <Lachy> | what if it was rgba(255, 0, 0, 0.1)? |
| 10:46 | <Hixie> | Philip` is the expert here |
| 10:46 | <Hixie> | i'm hoping he'll tell me what it should say :-) |
| 10:47 | <Hixie> | should i just explicitly say that you multiple the alpha channel with the rgb channels and use taht? |
| 10:47 | <Hixie> | multiply, that |
| 10:47 | <Philip`> | That sounds reasonable, though it might be easier to phrase it in terms of compositing the image onto a solid black background with source-in |
| 10:48 | <Philip`> | Uh |
| 10:48 | <Philip`> | source-over |
| 10:48 | <Philip`> | or it might not be, I don't know :-p |
| 10:49 | <Lachy> | Philip`, wouldn't compositing the image onto a solid white background give better results? |
| 10:49 | <Philip`> | (At least then rgba(255,0,0,0) will always come out as rgb(0,0,0), and it won't depend on the internal representation) |
| 10:49 | <Philip`> | Lachy: What does "better" mean? |
| 10:50 | <Lachy> | well, the resulting colours won't be dark |
| 10:50 | <Hixie> | Philip`: is this ok?: |
| 10:50 | <Hixie> | <p>For image types that do not support an alpha channel, the image |
| 10:50 | <Hixie> | must first be composited onto a solid black background using the |
| 10:50 | <Hixie> | source-over operator, and then exported.</p> |
| 10:50 | <Lachy> | what do image editors do in this situation? |
| 10:52 | <Hixie> | actually: |
| 10:52 | <Hixie> | + <p>For image types that do not support an alpha channel, the image |
| 10:52 | <Hixie> | + must be composited onto a solid black background using the |
| 10:52 | <Hixie> | + source-over operator, and the resulting image must be the one used |
| 10:52 | <Hixie> | + to create the <code title="">data:</code> URL.</p> |
| 10:53 | <Philip`> | Lachy: If you draw solid shapes onto the canvas, then it won't matter what the background colour is; and if you draw transparent objects, then try to save it to a format that doesn't support transparency, it's never going to work properly and it'll give unexpected results regardless of what we do |
| 10:54 | <Lachy> | ok, but it just seems more intuitive to me to use a white background |
| 10:54 | <Philip`> | so I guess what matters is just what's unexpected in the fewest cases |
| 10:55 | <Philip`> | Lachy: The image editors that I've used seem to use either white or the colour in the background position in your colour palette thing |
| 10:55 | <Lachy> | yeah, that's what I thought |
| 10:55 | <Philip`> | I wouldn't object to using white instead of black |
| 10:56 | <Philip`> | Hixie: It should perhaps be clearer that the compositing is creating a new temporary image, and not affecting the original at all |
| 10:56 | <krijnh> | "So it seems to be pointless to continue this discussion." - "Could you elaborate?" - huh? |
| 10:57 | <Hixie> | Philip`: that's what the second block above (which i committed) is trying to be more explicit about |
| 10:58 | <gDashiva> | Is Julian on IRC? |
| 10:59 | <krijnh> | In #html-wg, yes |
| 10:59 | <Philip`> | (Oops, got to go for an hour) |
| 11:01 | gDashiva | wonders if the whole thread could be killed off by a small IRC chat |
| 11:02 | <krijnh> | I have that idea with almost every thread on public-html :) |
| 11:04 | <Lachy> | it does indeed seem like our discussions in here are more productive than public-html sometimes. |
| 11:04 | <krijnh> | But in here there's no concept of concensus ;) |
| 11:04 | <krijnh> | Ow, wait :) |
| 11:18 | <gDashiva> | krijnh: I disagree, there's consensus all the time |
| 11:18 | <Hixie> | the reload thing works really well in webkit |
| 11:20 | <krijnh> | gDashiva: Yeah, but that's because Hixie kicks people who don't agree with him :) |
| 11:20 | <Hixie> | hah |
| 11:20 | <Hixie> | i haven't kicked anyone like ever from this channel :-P |
| 11:20 | <krijnh> | Luckily such lines aren't logged by me :) |
| 11:20 | <gDashiva> | Even if that were true, it would still be consensus in the channel |
| 11:20 | <Hixie> | actually we lost ops years ago |
| 11:20 | <Lachy> | /kick krijnh |
| 11:20 | <krijnh> | :+ |
| 11:20 | <gDashiva> | That's how the w3c consensus works, isn't it? They just keep people with common sense locked out :P |
| 11:20 | <Hixie> | hey woah watch out he does our logs! |
| 11:21 | <krijnh> | Yeah, watch out for my powers! |
| 11:22 | <Lachy> | there's a way to get ops back into the channel. I think it involves registerring the channel somehow |
| 11:23 | <gDashiva> | You need op to register, though :) |
| 11:23 | <Hixie> | i'm sad that nobody loves my little update tracking thingy |
| 11:23 | <Hixie> | except me |
| 11:23 | <Lachy> | I haven't seen it work yet |
| 11:23 | <krijnh> | This kicking thing reminds me of #css on Quakenet, when CounterStrike:Source was just released :P |
| 11:23 | <gDashiva> | They can probably make an exception, but the usual wisdom is that if the channel members can't coordinate a channel clearing, they aren't coordinated enough to need ops |
| 11:23 | <Hixie> | Lachy: odd, what browser? |
| 11:24 | <Lachy> | probably cause I haven't been paying attention. what exactly does it do? |
| 11:24 | <Hixie> | if you check the checkbox, it should let you know within 30 seconds of the spec being updated |
| 11:25 | <Lachy> | oh, nice |
| 11:25 | <Hixie> | (checking the checkbox also forces an immediate check) |
| 11:25 | <Lachy> | can you make the automatic updates checkbox more visible? |
| 11:25 | <Hixie> | sure |
| 11:25 | <Hixie> | where should i put it |
| 11:25 | <Lachy> | maybe put it up with the login box in the top right of the page? |
| 11:25 | <Hixie> | ok |
| 11:26 | <Lachy> | or in the Version History list |
| 11:29 | <Lachy> | Hixie, why don't you combine revision.dat and revision-message.dat, so it doesn't take 2 requests to get the info that could be obtained with one |
| 11:30 | <Lachy> | just make revision.dat contain a string like: |
| 11:30 | <Lachy> | r2006 Fixed Fix validation errors. |
| 11:30 | <Lachy> | and then split on the first space |
| 11:30 | <Lachy> | s/Fixed // |
| 11:31 | <Hixie> | mostly to make the backend easier |
| 11:31 | <Hixie> | it's all managed from shell scripts |
| 11:32 | <Lachy> | ok. |
| 11:32 | <Lachy> | Now that there's an API, I might be able to look into providing a DOM diff feature |
| 11:37 | <Lachy> | Hixie, what's the point of appending the '?[todays date]' to the URL for revision.dat? |
| 11:39 | <Hixie> | poor man's no-cache |
| 11:39 | <Lachy> | oh, why don't you just use a real Cache-Control header? |
| 11:40 | <Hixie> | it was easier than working out the correct .htaccess fu :-) |
| 11:40 | <Lachy> | ok |
| 11:41 | <hsivonen> | Hixie: have you considered allowing stuff like <org.webkit.canvas>? |
| 11:41 | <Hixie> | it is allowed |
| 11:42 | <Hixie> | oh you mean as a tag name |
| 11:42 | <hsivonen> | in the tag name |
| 11:42 | <Hixie> | that would have a terrible accessibility story |
| 11:42 | <Hixie> | the whole point of using class="" is that it has a fallback element that at least somewhat provides some semantics |
| 11:42 | <zcorpan> | everyone would just use divs anyway |
| 11:42 | <Hixie> | e.g. <p class="note"> instead of <ch.hixie.spec.note> |
| 11:42 | <hsivonen> | how's that worse than <span class='org.webkit.canvas'>? |
| 11:43 | <Hixie> | for browser vendors, the extension strategy is to come to the working group, ask for input for a few days, then mint a new element like <canvas> |
| 11:43 | <hsivonen> | Hixie: I agree |
| 11:44 | <Hixie> | so we're not talking about browser vendors or things like <canvas> here |
| 11:45 | <hsivonen> | well, <org.purl.dc.3.2.phase-of-moon-at-document-creation> |
| 11:46 | <Hixie> | then yes, <span class="org.purl.dc.3.2.phase-of-moon-at-document-creation"> is better |
| 11:46 | <Lachy> | I don't really understand what kind of extensions they're asking for. If it's just for personal/organisational site-specific use, then there's no problem to solve. If it's for wider use in the community, then letting them mint their own extensions without communication is a bad idea |
| 11:46 | <hsivonen> | Hixie: why? |
| 11:46 | <Hixie> | hsivonen: because then UAs don't have to worry about whether the element is inline or block, they can just look at whether it's a <div> or a <span> |
| 11:47 | <hsivonen> | Lachy: as far as I can tell, the problem is having to ask Hixie or Tantek. |
| 11:47 | <Hixie> | and for cases where there is a more appropriate semantic, there is built-in fallback |
| 11:47 | <Hixie> | they don't have to ask tantek, they can mint their own class names as they wish |
| 11:47 | <hsivonen> | Hixie: isn't span-likeness the default? |
| 11:48 | <Hixie> | hsivonen: it could be, but then the moment you wanted a block-likeness, or an emphasis-likeness, or an aside-likeness (as i really want for class=note) then you'd have to change to a different syntax |
| 11:48 | <Hixie> | Lachy: updated the ui, is it better now? |
| 11:48 | <hsivonen> | Hixie: you'd just use Cascading Semantic Sheets |
| 11:49 | <Hixie> | hsivonen: do you mean literally cascading style sheets, or tongue-in-cheek a hypothetical cascading semantic sheets? |
| 11:49 | <Lachy> | Hixie, yes |
| 11:49 | <hsivonen> | Hixie: both. |
| 11:49 | <hsivonen> | Hixie: display: block; |
| 11:50 | <Hixie> | hsivonen: for CSS, that doesn't help in the no-CSS case. for the latter, i don't understand how that would work in practice. i suggested it years ago before i realised how intractable the problem was. |
| 11:50 | <Hixie> | hsivonen: (in principle, we can't rely on CSS.) |
| 11:51 | <Hixie> | hsivonen: (and relying on CSS doesn't help turn the element into <aside> or <em> or whatever in media that i haven't written a sheet for) |
| 11:51 | <Hixie> | hsivonen: (which was in fact the very problem that came up today) |
| 11:51 | <hsivonen> | Hixie: I'm not seriously suggesting separation of semantics and structure |
| 11:52 | <hsivonen> | Hixie: but in practice, people (who don't consider accessibility of extensions) seems to be OK with including CSS for their custom stuff |
| 11:53 | <Hixie> | in practice, people (who don't consider accessibility) seem to be OK with doing everything with <font> and <table> and <img> and don't bother putting alt="" on their <img>s either |
| 11:53 | <Hixie> | but that doesn't mean we should allow any of that |
| 11:54 | hsivonen | is annoyed at dojotoolkit.org breaking Open Link in New Window |
| 11:55 | <hsivonen> | Hixie: not allowing it is centralized command |
| 11:55 | <Hixie> | ? |
| 11:55 | <Hixie> | can you rephrase that? i don't understand what you mean |
| 11:56 | <hsivonen> | Hixie: saying that people aren't allowed to do stuff is not Decentralized. |
| 11:56 | <Hixie> | and? |
| 11:57 | <hsivonen> | Decentralized Good, Centralized Bad, it seems :-) |
| 11:57 | <Hixie> | well then let's disband the w3c, the whatwg, the ietf, iana, and give up on web standards |
| 11:58 | <Philip`> | That's actually quite a good plan |
| 11:58 | <Hixie> | not if we want any kind of interoperability |
| 12:04 | <jgraham> | Hixie: Is there any actual problem with disallowing classnames that look like URIs but do not correspond to the requirements for minting URIs (e.g. that they are owned by the person who owns the domain name in the case of tag: URIs) |
| 12:04 | <Hixie> | it won't make him happy, is the problem |
| 12:04 | <Hixie> | because despite his love affair with uris, he also thinks they're ugly |
| 12:04 | <hsivonen> | Hixie: you could do with what XForms does with inputtypes |
| 12:04 | <jgraham> | It would solve about half the issues he has raised |
| 12:04 | <hsivonen> | and WF2 by reference |
| 12:05 | <Hixie> | which is? |
| 12:05 | <hsivonen> | Hixie: if the string contains a colon, it must be an absolute URL |
| 12:05 | <hsivonen> | basically denying the colon to those who don't love URIs an identifiers |
| 12:05 | <gDashiva> | That would kill off namespaces too :) |
| 12:05 | <jgraham> | hsivonen: URLs are worse than URIs in this case I think |
| 12:06 | <hsivonen> | jgraham: well, absolute IRI then |
| 12:06 | <hsivonen> | because URI wouldn't be internationalized |
| 12:06 | <hsivonen> | and we wouldn't want to leave things uninternationalized |
| 12:06 | <jgraham> | Yeah, OK :) |
| 12:07 | <gDashiva> | I'm wondering, though. What is there to prevent me from creating an awesome vocabulary using some company I don't relate to for the namespace URL? |
| 12:07 | <hsivonen> | gDashiva: you don't have the Authority! |
| 12:08 | <jgraham> | gDashiva: There are MUST NOT conditions! |
| 12:08 | <gDashiva> | So Hixie could add "@class identifiers MUST NOT conflict with other identifiers made by people who worry about conflicting identifiers" |
| 12:10 | <krijnh> | (why don't you guys talk about this with Julian, in #html-wg? You're all there as well) |
| 12:12 | <gDashiva> | We need to establish consensus first |
| 12:14 | <Lachy> | gDashiva, do you mean we need to get everyone to agree to move the conversation to the other channel, before we can move it? |
| 12:16 | <gDashiva> | Lachy: Yes, otherwise it wouldn't be backwards compatible with all the chatters |
| 12:16 | <Lachy> | alright. If that's what we're going to do, then we'd better organise an official survey announce it, give everyone sufficient time to answer it, and then come back in a couple of weeks with the results :-) |
| 12:17 | gDashiva | waves to the log watchers. |
| 12:18 | <Lachy> | I'm surprised by the total lack of discussion about the alt attribute changes. |
| 12:18 | <gDashiva> | I'm surprised the video thread died out so fast |
| 12:18 | <hsivonen> | we could just try switching and see if connections to irc.w3.org stay up and whether there will be Formal Objections |
| 12:18 | <krijnh> | Lachy: please don't be! I'm happy the way it is :) |
| 12:18 | <Lachy> | we had a total of 2 emails giving feedback about the spec, and one responding to say it was fixed. |
| 12:19 | <Lachy> | I'm happy too. Just very surprised. |
| 12:19 | <Lachy> | oh, and we also had one blog entry discussing process issues, rather than any technical issues. |
| 12:19 | <gDashiva> | hsivonen: We all know nothing good can come out of such unilateral implementations without sufficient evaluation in a peer group |
| 12:22 | <Hixie> | video thread? |
| 12:23 | <Hixie> | hsivonen: switching what? |
| 12:23 | <hsivonen> | Hixie: switching to discussing on #html-wg |
| 12:24 | <Hixie> | ah |
| 12:24 | <Lachy> | http://standardssuck.org/grddl-bridging-the-interwebs |
| 12:25 | <gDashiva> | Lachy: I don't have headphones, are there transcripts available? |
| 12:25 | <Lachy> | not yet. But you can try lip reading. |
| 12:26 | <Lachy> | "If you look at microformats just right, it's really RDF" Hah! :-) |
| 12:26 | <gDashiva> | Isn't everything RDF if you squint enough? |
| 12:27 | <Lachy> | he's giving a Matrix analogy |
| 12:27 | <Lachy> | talking about red and blue pills |
| 12:27 | <gDashiva> | Oh |
| 12:27 | <gDashiva> | heh |
| 12:31 | <zcorpan> | http://www.w3.org/2002/09/wbs/32212/calls4html2008aug/ |
| 12:32 | <hsivonen> | zcorpan: Has that questionnaire been announced to the HTML WG? |
| 12:33 | <zcorpan> | hsivonen: not afaik |
| 12:33 | <hsivonen> | zcorpan: is it for PFWG only? |
| 12:33 | <zcorpan> | hsivonen: not afaict |
| 12:36 | <zcorpan> | or maybe it is |
| 12:39 | <Lachy> | Decentralized Extensibility is to Namespaces what Intelligent Design is to Creationism" - hsivonen, do you mean Decentralised extensibility and namespaces are exactly the same thing? |
| 12:39 | <gDashiva> | No, that ID is a sneaky way to attempt to get acceptance for C |
| 12:39 | <Lachy> | because ID and creationism as the same thing, with a different name |
| 12:39 | <hsivonen> | Lachy: I mean that Decentralized Extensibility is a marketing fig leaf for Namespaces |
| 12:40 | <Lachy> | ok |
| 12:43 | <Hixie> | the red and blue pills is where i stopped watching that podcast |
| 12:43 | <Hixie> | i couldn't take it anymore |
| 12:43 | <Hixie> | too much truth that i couldn't handle, maybe, you decide :-) |
| 12:44 | <hsivonen> | http://annevankesteren.nl/2007/04/html-red-pill |
| 12:44 | <Lachy> | I haven't finished watching it either. |
| 12:44 | <gDashiva> | anne's post reminds me of final destination |
| 12:46 | <Hixie> | i'll be interested to see how sam responds to my last e-mail |
| 12:59 | <Lachy> | How can Julian claim that clashing namespace prefixes has never been a problem in practice, yet be so adamant about clashing class names being a problem? |
| 13:00 | <gDashiva> | Apparently there are lots of malicious authors who would gladly steal your class name and abuse it, but would never consider doing the same with a namespace because namespaces are holy |
| 13:02 | <hsivonen> | gDashiva: just like the XHTML namespace is holy and the XHTML2 WG has Authority over it despite browser vendors having the Power to pollute it with <canvas>. |
| 13:03 | <Hixie> | it's because nobody uses namespaces |
| 13:04 | Hixie | ducks |
| 13:05 | <gDashiva> | Hunt-and-peck = duck typing? |
| 13:07 | <Lachy> | nobody would use URI based class names either. They don't solve any real problems, that aren't solved by a simple organisational prefix, and even the benefits of such a prefix are questionable for private class names. |
| 13:08 | <gDashiva> | Hixie: What you suggested about only complicating the class=math classname, wouldn't that lead to the same copypaste problems namespaces is drowning us in? |
| 13:09 | <Hixie> | how so? |
| 13:09 | <Lachy> | so, I guess my problem is that I'm don't really understand the intended use cases they're trying to solve with whatever it is they're asking for, and it's not really that clear to me what they're asking for since URIs are supposedly ugly, yet they want a URI-based extension mechanism |
| 13:09 | <gDashiva> | Since the internal classnames would mean different things if you pasted them into a different container classname |
| 13:10 | <Lachy> | gDashiva, doesn't seem to have been a problem for microformats |
| 13:11 | <hsivonen> | Lachy: how do we really know what's a problem for microformats when parsing them is not documented, so we cannot evaluate parsing against real content |
| 13:11 | <Hixie> | yeah i really don't fully understand what is being requested either |
| 13:12 | <Hixie> | gDashiva: well that's like <circle> in svg not meaning anything useful outside of an <svg> container |
| 13:12 | <Hixie> | gDashiva: which isn't really a big problem |
| 13:12 | <Lachy> | maybe it would be better to wait and see if some sort of distributed extensibility design pattern emerges, and then once such a thing as proven itself, then we can spec it |
| 13:13 | <gDashiva> | Hixie: Yes. But if we entertain the idea of collisions, there could be a SillyVectorGraphics container and the cirle would be sillified when pasted there. |
| 13:13 | <Hixie> | Lachy: like, say, microformats? :-) |
| 13:13 | <Lachy> | so if a design pattern ever emerges that says to use reverse-dns domains, like class="org.example-foobar", and it becomes popular we could spec it |
| 13:13 | <Hixie> | gDashiva: yes, indeed. |
| 13:13 | <Lachy> | but, yeah, microformats seems to do well in that space anyway |
| 13:14 | <Hixie> | gDashiva: i don't see that as happening much though |
| 13:15 | <gDashiva> | Hixie: Agreed, but when the premise of disagreement is that collisions will happen, I thought it might be useful to see where that takes us :) |
| 13:17 | <Hixie> | gDashiva: it'll take us to the same place as people copying an <li> from an <ol> to a <ul>, or a <dt> from a <dl> to a <dialog> |
| 13:21 | <Hixie> | class="" is new? good to know |
| 13:21 | <Hixie> | (doesn't it predate xml, let alone xmlns?) |
| 13:23 | <Hixie> | ok, bed time (long past) |
| 13:24 | <Hixie> | nn |
| 13:33 | <gDashiva> | ... did I disconnect? |
| 13:34 | <gDashiva> | Hope our logger has a stable connection :) |
| 13:34 | <krijnh> | zzz |
| 13:36 | <gDashiva> | krijnh: Is your tagline list public? |
| 13:36 | <krijnh> | gDashiva: no :) |
| 13:36 | <gDashiva> | So you want us to brute force it, then? :) |
| 13:36 | <krijnh> | Well, in a way it is |
| 13:37 | <krijnh> | What do you want? |
| 13:37 | <zcorpan> | krijnh: how about an ajaxy button for the next tagline? |
| 13:37 | <gDashiva> | Something like that |
| 13:37 | zcorpan | has reloaded the page to see all taglines :) |
| 13:37 | <krijnh> | Really? |
| 13:37 | <krijnh> | So that's why my server load is so high |
| 13:37 | <gDashiva> | zcorpan: Are they sequential? |
| 13:37 | <krijnh> | I'm on ADSL lite you know.. |
| 13:37 | <zcorpan> | gDashiva: think so |
| 13:38 | <krijnh> | Are they? |
| 13:38 | <krijnh> | Cool feature |
| 13:38 | <zcorpan> | or maybe they aren't, don't remember |
| 13:38 | <krijnh> | There are 30 of them, collect 'm all! |
| 13:38 | <gDashiva> | krijnh: You should use semantic HTML to reduce download size |
| 13:39 | <krijnh> | Where can I download that? |
| 13:40 | <gDashiva> | Dunno |
| 13:40 | <Lachy> | hmm, I never noticed the tag line thing before |
| 13:40 | <krijnh> | Damn, it was developed especially for you! :( |
| 13:40 | <Lachy> | though I never go to the index page, since i have direct links to the latest logs of each channel in my history |
| 13:42 | <krijnh> | http://krijnhoetmer.nl/irc-logs/?gimme-a-hobby |
| 13:42 | <gDashiva> | That's a lot of style |
| 13:42 | <Lachy> | krijnh, are all these tag lines quotes from people on the maling list? Some of the sound familiar |
| 13:43 | <zcorpan> | krijnh: now make the tagline link to that |
| 13:44 | <krijnh> | Lachy: Some of them are |
| 13:44 | <krijnh> | I just thought it was funny |
| 13:44 | <krijnh> | And wasting time is one of the main reasons I joined the HTML WG (in retrospect), so why not :) |
| 13:45 | <Lachy> | krijnh, can you add an API for others to add new tag lines? |
| 13:45 | <Lachy> | maybe if we type a message beginning with "tag:", it could be added to your list |
| 13:45 | <krijnh> | Yeah, just pm me |
| 13:46 | <zcorpan> | tag: [off] will this show up? |
| 13:46 | <krijnh> | Yes |
| 13:46 | <krijnh> | It's only hidden in #webapps |
| 13:47 | <zcorpan> | if i write that in #webapps? |
| 13:47 | <zcorpan> | or is the tag: feature only for #whatwg? |
| 13:47 | <krijnh> | It's no feature |
| 13:47 | <krijnh> | It's a made up thing by Lachy :) |
| 13:47 | <zcorpan> | bug? |
| 13:47 | <zcorpan> | well you must implement it! |
| 13:48 | <zcorpan> | or i won't use your logs |
| 13:48 | zcorpan | invites zakim |
| 13:49 | <krijnh> | :'( |
| 13:49 | krijnh | tries to come with something similar for Opera.. |
| 13:50 | <zcorpan> | but you can't because opera has all features between the earth and the sun :) |
| 13:51 | <krijnh> | Indeed |
| 13:52 | <Lachy> | krijnh, has the [off] feature been used in #webapps at all for a legitimate purpose since the logs were officially activated? |
| 13:53 | <krijnh> | You shouldn't ask that question :) |
| 13:53 | <krijnh> | I think you know the answer already |
| 13:53 | <Lachy> | I actually don't. Though I could check my own logs, I guess |
| 13:54 | <zcorpan> | if you find something, could you quote it here? :P |
| 13:55 | <krijnh> | Cool, it has been |
| 13:55 | <gDashiva> | Lachy: It was used earlier today, by arve :) |
| 13:55 | <Lachy> | one said "[off] *sigh*" |
| 13:55 | <krijnh> | By an Opera employee :) |
| 13:56 | <zcorpan> | me? |
| 13:56 | <krijnh> | ARve |
| 13:57 | <Lachy> | I wouldn't really count that as legitimate use of it though, since it was designed to hide confidential information |
| 13:58 | <krijnh> | Jep |
| 13:59 | <gDashiva> | Have there been any more cases of 'oops, we are in a different channel' since that one time? |
| 15:08 | <virtuelv> | well, my sigh from earlier today was hardly relevant to what I was getting at |
| 15:24 | <hsivonen> | Hixie: what should I put into alt in the Image Report under the new spec text? alt="{image}"? That seems daft. |
| 15:36 | <Lachy> | hsivonen, alt={} might be reasonable for your case |
| 15:37 | <zcorpan> | jgraham: your outline tester doesn't work with entities |
| 15:37 | <Lachy> | is this for images from the website being validated, that are listed in image report table?? |
| 15:38 | <zcorpan> | jgraham: other than the 5 xml entities |
| 15:38 | <hsivonen> | Lachy: yes |
| 15:41 | <zcorpan> | hsivonen: "An image in an e-mail or document intended for a specific person who is known to be able to view images" still says alt may be omitted |
| 15:43 | <Lachy> | I asked why that is still in the spec, but Hixie seemed to miss that question when he responded to my mail |
| 15:43 | <Lachy> | I don't see why emails should be treated differently now that there's the {...} syntax |
| 15:44 | <Lachy> | they could just use alt={} or some auto generated thing like alt="{attached image}" |
| 15:49 | <hsivonen> | my crystal ball tells me that alt='{attached image}' will be in the UI language of the sender--not in the language of the message |
| 15:49 | <hsivonen> | in practice that is |
| 15:50 | <Lachy> | in practice, my UI language is the language I write in. So then I guess alt={} would be better, since it allows the recipient to be told in whatever langauge they use |
| 15:53 | <Lachy> | Hixie, please respond to the last question at the end of this mail http://lists.w3.org/Archives/Public/public-html/2008Aug/0090.html |
| 16:04 | <takkaria> | hehe, request on the libxml2 mailing list for libxml2 to silently ignore NUL bytes in XML rather than error on it |
| 16:05 | <gsnedders> | That's against the spec1111!11!! |
| 16:05 | <hsivonen> | takkaria: database dump use case? |
| 16:10 | <takkaria> | hsivonen: no idea for the use case, just someone complaining that libxml2 errors |
| 16:10 | <takkaria> | I have this sneaking suspicion that they may end up putting an input layer before libxml2 that silently ignores NULs |
| 16:54 | <gDashiva> | I wonder if anyone will ever suggest [on], so you can do like We don't want to give up our [off] secrets [on] to people like you! |
| 16:54 | <takkaria> | [off] does this not get logged then? |
| 16:54 | <gDashiva> | In here it does |
| 16:54 | <gDashiva> | But #webapps has special treatment |
| 16:55 | <takkaria> | ah |
| 16:59 | <Lachy> | heh, [off] is getting more use in here where it doesn't work, than it is in #webapps :-) |
| 16:59 | <zcorpan> | [off] [off] [off] [off] [off] [off] [off] [off] [off] [off] [off] [off] [off] |
| 17:02 | <gDashiva> | 4whoa |
| 17:02 | <jcranmer> | stress testing? |
| 17:02 | <gDashiva> | Netsplit maybe |
| 17:03 | <jcranmer> | 11:54 -!- Netsplit brown.freenode.net <-> irc.freenode.net quits: |
| 17:03 | <jcranmer> | but that doesn't explain zcorpan's comment (AFAIK) |
| 17:04 | zcorpan | updates http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F to match the spec |
| 17:04 | <zcorpan> | but it doesn't talk about foreign lands |
| 17:05 | <zcorpan> | [off] has the feature in here to make random people disconnect |
| 17:50 | <gsnedders> | Hixie: for no-num and no-toc, for header, should they be on the header element, or on the first highest h1–h6? |
| 18:00 | zcorpan | thinks Hixie is making an experiment with alt to see if accessibility experts are actually reading the spec or if they'll go "yep the spec is fine now that alt is always required" |
| 18:25 | <zcorpan> | Hixie: http://validator.whatwg.org/ has the old name in the link text |
| 20:01 | <davidmccabe> | Hixie: Hello. I'm considering writing up a proposal for drag-and-drop between browser windows. And I'm told you're the guy to talk to. |
| 20:01 | <davidmccabe> | I didn't find anything with google, but I thought I'd ask whether this has been proposed before to anyone's recollection. |
| 20:04 | <davidmccabe> | To summarize what I'm imagining: You would be able to set certain properties on DOM elements that make them draggable or droppable, and a javascript object would be passed from one window to the other when a drop is completed. |
| 20:04 | <davidmccabe> | The protocol could be modeled after those in Cocoa for instance. |
| 20:16 | <roc_> | HTML5 has a drag-drop spec |
| 20:16 | <roc_> | take a look |
| 20:17 | <roc> | you can't pass JS objects as drag data (that would present some problems), but you can pass strings |
| 20:21 | <davidmccabe> | Hah. |
| 20:21 | <davidmccabe> | I grepped the spec; how did I miss it? |
| 20:23 | <Hixie> | hsivonen: alt="{image from site}" maybe, or alt="{small image}" vs alt="{large image}", or some other categorising information that actually showing the image would convey (like size, transparency, colour) but that you would never actually write next to the image if the image was visible |
| 20:24 | <Hixie> | zcorpan: old name of what? |
| 20:24 | <Hixie> | davidmccabe: http://www.whatwg.org/specs/web-apps/current-work/#dnd |
| 20:25 | <davidmccabe> | Found it; sorry to bother you. |
| 20:25 | <Lachy> | this is weird, there seems to be a distinct lack of excitement over the upcoming olympic games ceremony in this country. I thought people here would be much more excited, but so far I've only heard from people who aren't that interested in seeing it |
| 20:25 | <Hixie> | np |
| 20:25 | <Dashiva> | Lachy: What country? |
| 20:25 | <Lachy> | Norway |
| 20:25 | <Lachy> | where I'm stuck living for now |
| 20:26 | <Dashiva> | Well, that's easy. Norway is all about winter olympics :) |
| 20:26 | gsnedders | is in Sweden |
| 20:26 | <Lachy> | wtf? who cares about the winter olympics?! |
| 20:26 | <gsnedders> | Lachy: Me! |
| 20:26 | <Dashiva> | Norway does |
| 20:26 | <gsnedders> | They're better than the summer ones! |
| 20:26 | <Lachy> | it's not as if Australians are going to win many medals at that one |
| 20:26 | <gsnedders> | The skeleton takes _real_ bravery |
| 20:26 | <Dashiva> | Lachy: Take your situation and reverse it to get Norway :P |
| 20:27 | <Lachy> | but we're champions in the pool, so I've gotta make sure I see those events |
| 20:27 | <Lachy> | especially the 1500 |
| 20:27 | <Lachy> | I hope Hackett wins that one again |
| 20:27 | <Dashiva> | Norway gets like a bronze in archery and a silver in solo rowing if we're lucky |
| 20:28 | <gsnedders> | Dashiva: You're from Norway? Ah. |
| 20:28 | <wilhelm> | There is a summer olymptics too? (c: |
| 20:28 | <Lachy> | wilhelm, yes! |
| 20:28 | gsnedders | knew you were from Scandinavia |
| 20:37 | <Dashiva> | gsnedders: Yes |
| 20:38 | <gsnedders> | Hixie: Answer me! ("for no-num and no-toc, for header, should they be on the header element, or on the first highest h1–h6?") |
| 20:40 | <Hixie> | oops, missed your question! |
| 20:41 | <Hixie> | you mean where should you look for it? |
| 20:41 | <Hixie> | i'd say h1-h6 element |
| 20:41 | <gsnedders> | Hixie: yeah |
| 20:41 | <Hixie> | for compat with bert's |
| 20:41 | <Hixie> | or just assume it for header descendants |
| 20:41 | <Hixie> | and don't look |
| 20:41 | <gsnedders> | Hixie: Nothing that uses Bert's uses <header> though, so it isn't really a compat issue |
| 20:41 | <Hixie> | it might become one if people migrate back :-) |
| 20:42 | <gsnedders> | Hixie: They won't! |
| 20:42 | gsnedders | grabs knive |
| 20:42 | <Hixie> | hah |
| 20:42 | <gsnedders> | *knife |
| 20:42 | <Hixie> | oh something came up in the public-html list that i was going to ask you to add to the specgen |
| 20:43 | <gsnedders> | Hixie: Well, it'd be useful to know what :) |
| 20:43 | <Hixie> | yeah i'm trying to work out how to phrase it |
| 20:44 | <Lachy> | gsnedders, adding "Note: ", "Warning: " and "**" to notes, warnings and issues |
| 20:45 | <Lachy> | replacing the current stylesheet approach |
| 20:45 | <Lachy> | that uses ::before and ::after |
| 20:45 | <Hixie> | basically yeah, but i have a specific markup style i'd like :-) |
| 20:46 | <gsnedders> | Hixie: Email, plz. |
| 20:46 | Lachy | suggests <strong class="ch.hixie.whatwg.spec.issue-marker">**</strong> :-) |
| 20:46 | <Hixie> | ok |
| 20:46 | <gsnedders> | (I'll probably lose it in IRC) |
| 20:46 | <Hixie> | e-mail addr? |
| 20:47 | <gsnedders> | geoffers⊙gc |
| 20:47 | <takkaria> | Lachy: not org.whatwg.spec.issue-marker? |
| 20:48 | <Lachy> | takkaria, I intentionally avoided using whatwg.org cause that would have been too obvious and not long enough |
| 20:48 | <Lachy> | gotta make sure it's globally unique |
| 20:49 | <gsnedders> | and it would conflict between w3c.org and whatwg.org |
| 20:49 | <Hixie> | yeah, i mean, you all have authority over whatwg.org too! |
| 20:49 | <takkaria> | hmm, maybe ch.hixie.whatwg.spec.html5.issue-marker, then? :P |
| 20:49 | <gsnedders> | Hixie: and power. Don't forget the power. |
| 20:49 | <Hixie> | none of us have any pwoer sadly |
| 20:50 | <Lachy> | takkaria, right. I forgot we needed to distinguish between webforms2 and webcontrols1 |
| 20:50 | <gsnedders> | Oh, there are multiple defs of single terms in WF2 |
| 20:57 | <Hixie> | gsnedders: you have mail |
| 20:57 | <Hixie> | don't worry abotu wf2 |
| 20:58 | <gsnedders> | That's why I didn't mention it before :) |
| 20:58 | <Hixie> | :-) |
| 20:59 | <gsnedders> | That should be doable |
| 20:59 | gsnedders | shoves that into the 1.1 list |
| 20:59 | <gsnedders> | (1.0 is, for all intents and purposes, feature frozen) |
| 21:00 | <takkaria> | Hixie: after WF2 is integrated and the form stuff is specced, HTML5 is actually pretty much feature complete isn't it? |
| 21:00 | <Hixie> | pretty much |
| 21:00 | <Hixie> | rendering section and aria are still missing |
| 21:16 | gsnedders | hopes he hasn't missed anyone out from the ack section of the spec-gen docs |
| 21:17 | <gsnedders> | "Andrew Sidwell, Anne van Kesteren, Henri Sivonen, Ian Hickson, James Graham, Lachlan Hunt, Magnus Kristiansen, Michael(tm) Smith, and Philip Taylor" + special thanks to Bert |
| 21:27 | <gsnedders> | Anyone think they should be in that list, do bully me |
| 21:29 | <gsnedders> | I also think I ought to stop hotlinking the whatwg style sheet ;P |
| 21:29 | <Hixie> | why? |
| 21:29 | <Hixie> | :-) |
| 21:29 | <takkaria> | gsnedders: I have no idea why I'm in there, but fair enough. :) |
| 21:30 | <gsnedders> | Hixie: So the docs work without an internet connection |
| 21:32 | <Hixie> | ah |
| 21:32 | <Hixie> | well |
| 21:32 | <Hixie> | details |
| 21:34 | <gsnedders> | takkaria: I was doing it from memory, and I think you've been at least as helpful as Dashiva :) |
| 21:36 | <virtuelv> | does anyone know anything about http://www.netsurf-browser.org/ ? |
| 21:38 | <hasather_> | virtuelv: takkaria I think :) |
| 21:38 | <Dashiva> | gsnedders: I don't even recall being helpful |
| 21:39 | <gsnedders> | Dashiva: Helpful by stopping me from getting bored :) |
| 21:39 | <Dashiva> | So the bar for getting credit is pretty low then :) |
| 21:40 | <takkaria> | Rob Burns might also qualify |
| 21:41 | <gsnedders> | takkaria: he doesn't make me laugh, though |
| 21:42 | <gsnedders> | http://spec-gen.gsnedders.com/ — a website! |
| 21:43 | <virtuelv> | gsnedders: does that do all of what the css3 module post-processor does? |
| 21:44 | <gsnedders> | virtuelv: No. It does most of what people use, though. All of what Hixie uses, for example. |
| 21:44 | virtuelv | checks out a copy |
| 21:45 | <gsnedders> | virtuelv: http://stuff.gsnedders.com/spec-gen — examples |
| 21:45 | <takkaria> | gsnedders: the link to w3.org in section 3 is preceded by a ">" |
| 21:45 | <gsnedders> | takkaria: in the docs? |
| 21:46 | <gsnedders> | Oh, yeah |
| 21:50 | <gsnedders> | takkaria: fixed |
| 21:55 | <Hixie> | is there any way to create a DOM Document object in IE that doesn't involve an HTML parser? |
| 21:57 | <Hixie> | w(new ActiveXObject("Msxml.DOMDocument").readyState); |
| 21:57 | <Hixie> | ...returns 4. |
| 21:57 | <Hixie> | wtf. |
| 22:17 | <Hixie> | should we rename "irrelevant" to "hidden"? It's what we have on <command> for the same basic semantic... |
| 22:17 | <Hixie> | but I don't want people to just use it to hide things, it's more subtle than that... |
| 22:17 | <Hixie> | though i guess nobody will understand the subtleness... |
| 22:17 | <Hixie> | hmm. |
| 22:18 | <gsnedders> | Hixie: irrelevant, plz. |
| 22:18 | <gsnedders> | :P |
| 22:18 | <Hixie> | it's harder to type, and people don't get it |
| 22:19 | <gsnedders> | Hixie: then @useless? |
| 22:19 | <Lachy> | Hixie, hidden is better |
| 22:19 | <Hixie> | ooh, that's not a bad name |
| 22:19 | <Lachy> | or ignore="" |
| 22:20 | <Hixie> | it would be ignored="" but yeah, that might work too |
| 22:20 | <Hixie> | one example of something for which i think this attribute isn't appropriate is hiding one panel of a tabbed panel in a dialog when another panel is active |
| 22:21 | <Hixie> | because the fact that the controls are tabbed isn't intrinsic to the dialog, it's just a presentation |
| 22:21 | <Lachy> | it might be a little unintuitive for e.g. <script ignored="">, since AIUI, the script would still execute. |
| 22:22 | <webben> | Hixie: inactive or ignore would be better than irrelevant or hidden. |
| 22:22 | <webben> | irrelevant is just confusing; hidden is confusing presentational |
| 22:22 | <webben> | *confusingly |
| 22:22 | gsnedders | waves g'nite |
| 22:23 | <webben> | IIRC someone was arguing re inactive that people would misspell it. |
| 22:23 | <Lachy> | whatever you choose, change hidden="" for command to be the same |
| 22:23 | <Lachy> | or just drop hidden from command, and let it use the global attribute |
| 22:24 | <jgraham> | inactive is good hidden and ignore is bad |
| 22:24 | <Lachy> | why is ignore bad? |
| 22:24 | <webben> | Lachy: because parsers shouldn't ignore the markup for instance |
| 22:24 | <webben> | and because events can still be fired for it (IIRC) |
| 22:24 | <jgraham> | ignore sounds too mch like "don't look at the man behind the curtian" |
| 22:25 | <jgraham> | If it should be ignored why is it there? |
| 22:25 | <Lachy> | webben, so? That's why we're not calling it dont-parse="" |
| 22:25 | <jgraham> | Whereas inactive seems like a good description of the semantic |
| 22:26 | <Lachy> | inactive might work |
| 22:27 | <webben> | hmm on the other hand "Elements in a section hidden by the irrelevant attribute are still active, e.g. scripts and form controls in such sections still render execute and submit respectively" |
| 22:27 | <webben> | note "active" |
| 22:28 | <webben> | from http://www.whatwg.org/specs/web-apps/current-work/#the-irrelevant |
| 22:32 | <Lachy> | Hixie, the new spec update system has already proven much more useful than twitter |
| 22:32 | <Lachy> | I tend to ignore most twitter messages, so I rarely saw the whatwg ones |
| 22:33 | Lachy | goes to stop following whatwg twitts |
| 22:37 | <Hixie> | inactive is too much like "disabled" |
| 22:38 | <Hixie> | Lachy: cool, glad to hear it! |
| 22:44 | <Lachy> | Hixie, so Web Controls is now officially dead? |
| 22:44 | <Lachy> | I was wondering what was going to happen with it |
| 22:45 | <Hixie> | it's not officially anything |
| 22:45 | <Hixie> | i don't know what will happen to it |
| 22:45 | <Hixie> | certainly ARIA has somewhat addressed one of the big use cases for web controls 1.0 |
| 22:45 | <Hixie> | though imho in a less good way, but that's another story |
| 22:46 | <Hixie> | i think i'm gonna drop autosubmit from <menu> |
| 22:46 | <Hixie> | it doesn't seem to have a compelling use |
| 22:47 | <Lachy> | what was it designed for originally? |
| 22:47 | <Hixie> | i'm not sure |
| 22:49 | <Lachy> | oh, it was designed for menus made with <select> that automatically submit, which is commonly done with JavaScript |
| 22:49 | <Lachy> | I think |
| 22:49 | <Hixie> | that's what i thought but the way it was defined only affected radio and checkbox inputs, and the example in the source that used autosubmit with a <Select> had JS that woudl take care of the submission anyway for legacy UAs |
| 22:49 | <Hixie> | so.. |
| 22:50 | <Lachy> | is the disabled-javascript case not worth considering? |
| 22:51 | <Hixie> | i don't think it's worth a whole extra attribute here |
| 22:53 | <Lachy> | I couldn't see any example in the spec using autosubmi |
| 22:53 | <Lachy> | was it hidden in a comment? |
| 22:53 | <Hixie> | yes |
| 23:27 | Philip` | finally gets his box working again |
| 23:28 | <Philip`> | It kind of stopped networking, and then I guess it didn't like having around a year of software updates without being rebooted so it didn't start up trivially :-( |
| 23:28 | <jcranmer> | O_O |
| 23:29 | <Philip`> | Hixie: Is there some way you could modify your script that calls the multipage generator, so that if e.g. hypothetically the server running the multipage generator was done for some hours, it wouldn't start seven simultaneous requests to generate the multipage spec once it came back up? |
| 23:29 | <Hixie> | yeah, that should be possible |
| 23:30 | <Philip`> | Hopefully it shouldn't ever be necessary, so don't worry if it's a non-zero amount of effort :-) |
| 23:32 | <Hixie> | done |
| 23:33 | <Hixie> | (just changed -t 0 to -t 1 in the wget command line) |
| 23:33 | Philip` | won't test the changes |
| 23:33 | <Philip`> | so I'll just assume they'll work, and so I'll say thanks |