| 00:21 | <Hixie> | Hm, I should make the RDF conversion algorithm ignore itemprop=""s that have no ":" or "." if the item="" was empty |
| 00:36 | <othermaciej> | Hixie: got a second to talk about ARIA? |
| 00:37 | <Hixie> | sure |
| 00:37 | <Hixie> | we just passed r3600 |
| 00:37 | <othermaciej> | woot! |
| 00:37 | <othermaciej> | ok so |
| 00:37 | <Hixie> | if we rotated one degree for each revision, we'd be very dizzy by now, but facing the same way as we started. |
| 00:38 | <Hixie> | little known useless facts, brought to you by Ian. |
| 00:38 | <Dashiva> | I think it's not that little known :P |
| 00:38 | <Hixie> | well if i hadn't told you we'd reached r3600 first :-P |
| 00:39 | <Philip`> | If you'd worked faster and done one commit per second, it would only have taken an hour to reach this far instead of five years |
| 00:39 | <Dashiva> | Now that's a useful fact |
| 00:39 | <Hixie> | lol |
| 00:39 | <Hixie> | actually the repo started in like 2006 or 2007 or something |
| 00:40 | <Dashiva> | So like 4 edits per day |
| 00:40 | <Hixie> | sounds about right |
| 00:41 | <Philip`> | r1 | ianh | 2006-03-02 23:11:05 +0000 (Thu, 02 Mar 2006) | 1 line |
| 00:41 | Hixie | wonders where othermaciej went |
| 00:41 | <Dashiva> | Candlejack |
| 00:42 | <othermaciej> | Hixie: got interrupted, hang on a sec |
| 00:42 | <Hixie> | i have a hard out in 15 minutes |
| 00:42 | <othermaciej> | Hixie: Sam convinced one of the PFWG big shots to attend tomorrow's telecon and possibly talk about the blocking last call issues on ARIA |
| 00:44 | <othermaciej> | Hixie: I'm not even going to ask you to attend, but I plan to |
| 00:44 | <othermaciej> | Hixie: I'd like to understand your Last Call comments and other objections clearly, so I can give informed comments on their plans |
| 00:44 | <Hixie> | i'll be asleep and far from any phones at the time of the telecon |
| 00:45 | <othermaciej> | Hixie: to be clear - is your concern solely about document conformance, and leaving HTML5 the freedom to define "nonsense" states as nonconforming? |
| 00:45 | <Hixie> | othermaciej: i think you understand them -- we just want to be able to have well-defined conformance criteria for authors that are sane (no radiobutton checkboxes or headers that aren't headers or whatnot), and well defined conformance criteria for implementations when the author ones are ignored. |
| 00:46 | <othermaciej> | Hixie: let me ask you about one hypothetical |
| 00:47 | <othermaciej> | let's say it is defined that in the <input type="radiobutton" role="checkbox" checked aria-checked="false"> case.... |
| 00:48 | <othermaciej> | conformance checkers were allowed to flag the checked/aria-checked conflict as nonconforming, and specs were allowed to specifically define cases as nonconforming, and "native" state is defined to take precedence for implementations |
| 00:48 | <othermaciej> | would it be important to have the same for role, so that for example <input type="radiobutton" role="checkbox" checked> can be disallowed by the host language? |
| 00:48 | <othermaciej> | I think your answer will be that, yes, conflicting roles should be disallowed even if no other state is conflicting |
| 00:48 | <Hixie> | i think that's important, yes |
| 00:48 | <othermaciej> | but I want to confirm |
| 00:49 | <Hixie> | i'd like to make any contradictions between html semantics and aria semantics a conformance error |
| 00:49 | <othermaciej> | all right, I think I can give them an informed opinion tomorrow, in that case |
| 00:49 | <Hixie> | and i'd like to make any such contradictions have crystal clear implementation requirements, ideally requirements that cause the visual semantics to be propagated to the AT even if the aria semantics would contradict the visual semantics |
| 00:50 | <Hixie> | i.e. native semantics should win (i think that would lead to more accessible pages) |
| 00:50 | <othermaciej> | roger that |
| 00:50 | <Hixie> | e.g. <h1 role=checkbox> shouldn't be valid either, and should act like an <h1> to ATs, not a checkbox |
| 00:50 | <othermaciej> | I'm assuming that <div>, for example, would have null intrinsic semantics and thus be compatible with any ARIA role |
| 00:50 | <Hixie> | right |
| 00:50 | <Hixie> | seems likely |
| 00:50 | <Hixie> | i haven't checked all the roles, but i assume that would be true |
| 00:51 | <othermaciej> | I can also imagine some elements might be compatible with other roles despite having a default one, though I have not checked the list in detail either |
| 00:53 | <othermaciej> | for example, they have an example of giving <li> a menuitem role, which seems reasonable since lists are often used as menus (whether pop-up or static) |
| 00:53 | <Hixie> | seems reasonable |
| 00:54 | <Hixie> | ok i gotta go |
| 00:54 | <Hixie> | bbl |
| 00:55 | <othermaciej> | later! |
| 07:25 | <gsnedders|work> | Hixie: yt? |
| 07:26 | <Hixie> | here |
| 07:28 | <annevk5> | guess rubys and I were not talking about the same issue then :/ |
| 07:29 | <hsivonen> | Hixie: when the user presses the stop button, does the tokenizer need to emit EOF? |
| 07:29 | <gsnedders|work> | Hixie: Can I have a copy of the source of html5? |
| 07:29 | <Hixie> | hsivonen: unspecified currently. probably yes. |
| 07:29 | <Hixie> | gsnedders|work: sure http://www.whatwg.org/specs/web-apps/current-work/source |
| 07:30 | <hsivonen> | Hixie: it's a bit of a problem in Gecko... |
| 07:30 | <Hixie> | gsnedders|work: or do you mean the source i sent to pimpmyspec.net? |
| 07:30 | <gsnedders|work> | Hixie: With header :) |
| 07:30 | <Hixie> | oh |
| 07:30 | <gsnedders|work> | Hixie: yes |
| 07:30 | <Hixie> | hm |
| 07:30 | <hsivonen> | Hixie: Gecko wants the stop button to kill the parser synchronously |
| 07:30 | <Hixie> | hsivonen: we can probably allow various implementations, interop is of little consequence in that case |
| 07:31 | <hsivonen> | Hixie: OK. thanks |
| 07:31 | <Hixie> | hsivonen: send mail if you want the spec to mention it, otherwise, it's just a UI feature and out of scope, your choice |
| 07:31 | <Hixie> | gsnedders|work: hold on, i'll have to get my script to generate the temp file then abort it |
| 07:31 | <Hixie> | gsnedders|work: whatwg or w3c? |
| 07:31 | <gsnedders|work> | Hixie: I was guessing it would be something like that |
| 07:31 | <gsnedders|work> | Hixie: either/both |
| 07:32 | <hsivonen> | Hixie: the thing is, there are more than UI features that trigger the same behavior |
| 07:32 | <hsivonen> | Hixie: specifically, app cache can cause stop button-like behavior |
| 07:32 | <Hixie> | my script generates 10 difference files that it then uses as input to the various processors like anolis |
| 07:32 | <hsivonen> | Hixie: in which case a synchronous EOF is bad, bad |
| 07:32 | <Hixie> | different, rather |
| 07:32 | <Hixie> | gsnedders|work: http://www.whatwg.org/specs/web-apps/current-work/source-whatwg-html5 |
| 07:33 | <Hixie> | gsnedders|work: grab it now, it'll get nuked next time i run the script |
| 07:33 | <gsnedders|work> | Hixie: thx |
| 07:37 | <Hixie> | hsivonen: that's more like location.replace() behaviour, i think |
| 07:37 | <Hixie> | hsivonen: though if you don't think that's clear enough, send mail |
| 07:37 | <Hixie> | afk for a while |
| 07:39 | <hsivonen> | Hixie: I think I'll create a patch. if it works, I'll feed the result back into the spec |
| 07:40 | <othermaciej> | evening, folks |
| 07:40 | <othermaciej> | annevk5: what issue? |
| 07:41 | <othermaciej> | hsivonen: are you going to be at the telecon? |
| 07:44 | <hsivonen> | othermaciej: I have other commitments that will prevent me from being there properly |
| 07:45 | <othermaciej> | hsivonen: no prob, just wanted to know |
| 07:45 | <othermaciej> | I told Sam I would be there to be able to explain the ARIA integration issues, and comment on the PFWG's sneak preview of their proposed resolution thereof |
| 07:45 | <othermaciej> | it would be nice to have backup from someone who know the issues but I can do without |
| 07:47 | <annevk5> | othermaciej, oh, in http://krijnhoetmer.nl/irc-logs/whatwg/20090812#l-315 Sam Ruby seemed to be talking about Last Call so I asked what needed helping and he replied with links just about the <canvas> accessibility discussion in the end |
| 07:48 | <othermaciej> | annevk5: I think the group of accessibility folks who want to make a canvas accessibility proposal may need help from people who know a lot about how canvas works |
| 07:49 | <othermaciej> | annevk5: I'm not entirely convinced this is the most problematic issue, but it does seem to be the one with the farthest-out action item due date |
| 07:50 | gsnedders|work | realizes why PMS uses UTF-8, he thinks |
| 07:55 | <annevk5> | othermaciej, it would be best to get help from people who made desktop apps written in some graphics library accessible, methinks |
| 07:55 | <othermaciej> | annevk5: that might be better |
| 07:56 | <othermaciej> | annevk5: if some of the relevant accessibility people are there, I'd like to hear from them what kind of help they want, and see if I can convince someone with the right skills to help them make a proposal sooner rather than later |
| 08:03 | <jgraham> | gsnedders|work: Do tell |
| 08:04 | <gsnedders|work> | jgraham: Were you still using your own modified Anolis before updating? |
| 08:04 | <gsnedders|work> | jgraham: Which had a subtly different API, as I changed it slightly when merging? |
| 08:04 | <jgraham> | gsnedders|work: Could be |
| 08:05 | <gsnedders|work> | jgraham: I want PMS source! :P |
| 08:05 | <gsnedders|work> | jgraham: Also see html5lib #111 |
| 08:06 | <jgraham> | gsnedders|work: If you want the source why not look at it? |
| 08:07 | <jgraham> | gsnedders|work: Yeah I just got that bug report |
| 08:07 | <jgraham> | html5lib really really needs some love |
| 08:08 | <gsnedders|work> | jgraham: Where is the PMS source? I forget |
| 08:09 | <jgraham> | hg.hoppipolla.co.uk |
| 08:11 | gsnedders|work | guessed that, but his Icelandic wasn't up to spelling it :) |
| 08:14 | <gsnedders|work> | jgraham: encoding needs to be output_encoding |
| 08:14 | <gsnedders|work> | jgraham: I can email you a patch |
| 08:15 | <othermaciej> | jgraham: did you manage to find your non-author-content-stripping script? |
| 08:19 | <jgraham> | othermaciej: Yeah I am integrating it into anolis |
| 08:19 | <othermaciej> | sweet |
| 08:19 | <jgraham> | Hold on and I will upload some sample output |
| 08:19 | <jgraham> | gsnedders|work: Clearly it doesn't work |
| 08:23 | <jgraham> | gsnedders|work: A patch would be welcome |
| 08:24 | <jgraham> | othermaciej: http://hoppipolla.co.uk/410/output.html |
| 08:24 | <gsnedders|work> | jgraham: Is it not always using html5lib to parse now, on PMS? |
| 08:25 | <jgraham> | Literally the first time I have run the code so probably horribly wrong |
| 08:25 | <jgraham> | gsnedders|work: Maybe. Did you change something else too? |
| 08:25 | <annevk5> | hmm, fun -- http://mail.apps.ietf.org/ietf/charsets/msg00146.html -- and here I thought UTF-8 was fine |
| 08:27 | <gsnedders|work> | jgraham: http://hg.hoppipolla.co.uk/hgwebdir.cgi/anolis/rev/a9fb72b5d3b8 |
| 08:27 | <hsivonen> | annevk5: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/207 |
| 08:27 | <hsivonen> | annevk5: in WebKit |
| 08:27 | <annevk5> | oh lol, that message was from94 |
| 08:28 | <annevk5> | that charset archive is old |
| 08:28 | <annevk5> | hsivonen, hmm, so I didn't test very well |
| 08:28 | <annevk5> | sorry |
| 08:32 | <gsnedders|work> | jgraham: sent |
| 08:34 | <jgraham> | gsnedders|work: Thanks |
| 08:34 | jgraham | will change locations now |
| 08:34 | <gsnedders|work> | Oh noes! |
| 08:34 | <gsnedders|work> | He's coming to get me! |
| 09:22 | <jgraham> | Hixie: Do you just use regexps to split the spec source into different documents? |
| 09:22 | <jgraham> | In any case do you mind sharing what you do? |
| 09:23 | <hsivonen> | http://intertwingly.net/blog/2009/08/12/Mountain-Mohammed-Mohammed-Mountain-Please-Talk#c1250141438 |
| 09:23 | <hsivonen> | aside: when did VH1 one stop being the grown-up version of MTV as a music channel and started to show "dating" "reality" |
| 09:24 | <hsivonen> | ? |
| 09:24 | <hsivonen> | s/one / |
| 09:44 | <jgraham> | hsivonen: Probably when they realised it was easier to sell ads for that than for music videos |
| 09:55 | <Lachy> | if we split out the canvas API, I wonder if the public-canvas-api mailing list that was set up a year and half ago for this purpose would finally see some use, or if the work would moved to public-webapps or stay within public-html |
| 09:56 | jgraham | has no idea how splitting out the canvas api would work |
| 09:57 | <Lachy> | presumably, it would take the CanvasRenderingContext2D API, leaving the actual element within HTML5 and have normative references between the two specs |
| 09:58 | <jgraham> | That seems like the type of complex surgery that leads to undefined behaviour in the gaps |
| 10:03 | <Lachy> | why? How would defining the 2D context in a separate spec pose any more challenges than defining a 3D context, which is currently being worked on elsewhere |
| 10:07 | Philip` | doesn't see why it would be complex, as long as you don't mind having lots of normative references to the HTML5 spec |
| 10:07 | <jgraham> | Well the 3D effort hasn't actually produced any interoperable implementations yet so you can't really use it as an example of why it will work |
| 10:08 | <Philip`> | (I don't think there'd need to be normative references from HTML5 to the Context2D spec, unless I'm forgetting things) |
| 10:09 | <jgraham> | Maybe if all the references are in one direction it will work better. |
| 10:09 | <Lachy> | Take whole of section 4.8.11.1 The 2D context, and most of 4.8.11.3 Security with canvas elements (the parts specific to where the 2D context api sets the origin-clean flag) and put it into it's own spec |
| 10:10 | <Lachy> | and have most of the normative references go from the 2D API spec to HTML5, with just one normative reference from HTML5 to say that implementations must support the 2D context |
| 10:10 | <Philip`> | Why do you need to say they must support the 2D context? |
| 10:10 | <jgraham> | However I would still worry about people assuming that some issue will be defined in HTML5 and HTML5 assuming that the context defines the issue |
| 10:11 | <jgraham> | And I don't see anyone who benefits from splitting it out |
| 10:11 | <Lachy> | you could possibly get away without requring support for it, but in reality, implementations need to support it regardless |
| 10:12 | <jgraham> | Since implementors implement things when they think their users want them not when the spec reaches a certian stage |
| 10:12 | <Lachy> | jgraham, i'm not saying it's a good idea. Just that it's possible to do so if a) someone volunteers to edit it, and b) the HTMLWG decides it's a good idea |
| 10:12 | <Philip`> | I imagine one possibly tricky issue is mixing contexts (e.g. you draw a 3D scene, and then draw a 2D rectangle on it, then draw some more 3D, and what ends up in the bitmap?) which would need to be defined in some central place but might depend on details of the contexts |
| 10:13 | <Philip`> | Lachy: In reality they need to support GIF and PNG and JPEG too, but the specs don't need to tell them that |
| 10:13 | <Lachy> | yes, I know that |
| 10:13 | <jgraham> | Practically I don't think it makes a jot of difference if HTML5 becomes a Rec. without accessibility hooks for canvas, as long as the work on those hooks is actually happening |
| 10:14 | <hsivonen> | what happens if you draw on both 2D and OperaGame contexts? |
| 10:14 | <Philip`> | Lachy: so need for support doesn't much relevance on your proposed need to make HTML5 require support |
| 10:14 | <gsnedders|work> | But then they aren't valid HTML 5, and that's the end of the world as we know it (and I feel fine) |
| 10:14 | <jgraham> | Because no implementor will go "oh we can't make out <canvas> implementation accessible because that is a HTML6 feature and we are only working on HTML5 features" |
| 10:14 | <Philip`> | hsivonen: You can't draw on opera-2dgame contexts |
| 10:14 | <jgraham> | And authors only care about what is implemented |
| 10:14 | <gsnedders|work> | jgraham: A lot of authors care about validity, though |
| 10:15 | <Philip`> | hsivonen: but you can use it to access the canvas bitmap state, and the 2D context path state |
| 10:15 | <hsivonen> | Philip`: ah |
| 10:15 | <jgraham> | gsnedders|work: Since canvas accessibility will almost certianly not involve static markup but DOM APIs that isn't very relevant |
| 10:16 | <jgraham> | Anyway I don't imagine we will get consensus on the view that practicaility beats purity |
| 10:16 | <Lachy> | Philip`, I didn't use that as an argument for why there needs to be a normative reference. I agreed with you that we could get away without it. I just noted that it would need to be supported anyway |
| 10:17 | <Philip`> | Lachy: Okay, so there doesn't need to be a normative reference from HTML5 to 2D, so it's all nice and one-way :-) |
| 10:17 | <Philip`> | Well, except for things like examples in the HTML5 spec |
| 10:19 | <Philip`> | and things like references to the 2D API for colour space explanations |
| 10:19 | <Lachy> | Philip`, I don't see why mixing a 2D context and a 3D context would be tricky, as each one draws immediately over the top of whatever else was put there before it. It's like paiting with one brush, picking up another and painting with that and then going back to the first brush. |
| 10:20 | <Lachy> | it might not give particularly sensible results if the authors wasn't careful, but it would allow authors to draw 3D objects in a 2D scene, which might give some nice effects |
| 10:21 | <Philip`> | Lachy: Implementations don't use paint brushes - they use buffers in system memory and other buffers in video memory and have to efficiently transfer data between buffers until it eventually ends up on the screen |
| 10:21 | <Philip`> | and arbitrarily mixing 2D and 3D sounds like something that might be complex to implement correctly and efficiently |
| 10:23 | <Philip`> | And if you draw a 3D scene, then draw a 2D rectangle onto it, what happens to the depth buffer underneath the rectangle? |
| 10:29 | <Hixie> | gsnedders|work, is your e-mail supposed to mean something to me? :-) |
| 10:29 | <Lachy> | it wouldn't affect it. Any depth information would be maintained by the 3D context object, which isn't relevant after the image has been drawn on the actual canvas. So the 2D context would just draw on top of it without knowing anything about the previously drawn 3D image, and likewise when the 3D context draws again |
| 10:31 | <Philip`> | Lachy: When the 3D image is drawn onto the canvas, the entire buffer will be copied, so it'll overwrite any 2D stuff that was drawn before |
| 10:31 | <Lachy> | right |
| 10:31 | <Philip`> | so you couldn't usefully mix 2D and 3D |
| 10:32 | <Philip`> | (Well, I suppose you could still draw 2D on top of 3D) |
| 10:32 | <Philip`> | (but not the other way around) |
| 10:32 | <Lachy> | why is there a difference? |
| 10:33 | <othermaciej_> | 3D drivers like to own a rectangle |
| 10:33 | <othermaciej_> | it's possible to do 2D drawing using 3D APIs though |
| 10:33 | <jgraham> | It sounds like this will need to be defined |
| 10:33 | <othermaciej> | but currently no one does |
| 10:34 | <Philip`> | Lachy: The 2D drawing operations can modify the canvas bitmap directly; 3D drawing usually works in its own hardware-accelerated world and then gets copied to the canvas, so it ignores whatever's already in the canvas bitmap |
| 10:34 | <jgraham> | Since it sounds like there are two possible approaches (at least) |
| 10:34 | <Philip`> | (hence the difference) |
| 10:34 | <othermaciej> | however using 2D for 3D drawing is tricky |
| 10:34 | <jgraham> | Philip`: Presumably one could keep the whole canvas bitmap in the 3D world |
| 10:35 | <Philip`> | (assuming the 2D drawing isn't hardware-accelerated too) |
| 10:35 | <jgraham> | Somehow |
| 10:36 | <othermaciej> | (because at least older versions of OpenGL are not good about anti-aliasing of polylines or polygons, and are pretty bad at drawing text as well) |
| 10:36 | <Philip`> | jgraham: One could, e.g. Mozilla uses Cairo which has some OpenGL/DirectX backends (though apparently they're not great) |
| 10:36 | <othermaciej> | I can ask my more graphics-oriented colleagues who are in the WebGL group to raise this issue |
| 10:39 | <othermaciej> | I expect mixing 2D and 3D will do weird and non-interoperable things in the first cut, but I'm also not sure it is a terribly important use case |
| 10:40 | <Philip`> | othermaciej: Could be useful to ask - it seems like it'd be nice to have sensible interactions between 2D and 3D contexts, e.g. you could render a 3D scene then use getImageData to apply an edge filter |
| 10:58 | <roc> | othermaciej: WPF uses 3D *hardware* for accelerated 2D drawing, very aggressively |
| 10:59 | <roc> | using getImageData to apply edge filters when you have 3D hardware available is grotesque |
| 10:59 | <othermaciej> | roc: it might be that modern 3D hardware does everything you need for 2D graphics |
| 11:01 | <Philip`> | What's wrong with grotesque? :-) |
| 11:02 | <roc> | grotesque is tolerable |
| 11:02 | <roc> | incredibly slow is not |
| 11:02 | <Philip`> | You just need to make your JS engine faster :-p |
| 11:02 | <roc> | well |
| 11:03 | Philip` | can't currently think of any really compelling use cases for mixing 2D and 3D APIs |
| 11:03 | <roc> | even a hand-tuned vectorized assembly language edge filter running on the CPU is going to be orders of magnitude slower than a GPU-based implementation |
| 11:04 | <Philip`> | You just need to make your JS engine run on the GPU, then |
| 11:04 | <roc> | that was my line |
| 11:05 | <Philip`> | How hard can it be? |
| 11:06 | <roc> | we definitely want to be using a cairo GL backend so we can mix 2D rendering, 3D rendering and custom GPU programs efficiently |
| 11:06 | <roc> | there are quite a few places we could use the GPU to speed up regular Web browsing |
| 11:07 | <roc> | but there's so much else to do... |
| 11:07 | <roc> | fortunately cairo-gl is making progress on its own |
| 11:30 | <hsivonen> | Philip`: it's quite common to want to draw a HUD over a 3D scene and to use high-quality fonts on the HUD |
| 11:31 | <hsivonen> | Philip`: doing it with a 3D API tends to be annoying |
| 11:36 | <Philip`> | hsivonen: Ah, text sounds like a good example |
| 11:36 | <Philip`> | though would you necessarily want to use the 2D API directly on top of the 3D image, when you could easily create a temporary canvas and do some 2D text drawing then load it as a texture into the 3D canvas API? |
| 11:37 | <hsivonen> | Philip`: well, the texture loading so that there's no pixel supersampling and so that it gets mapped to a plane that is guaranteed to be perpendicular to the line of sight is annoying |
| 11:38 | <hsivonen> | Philip`: it's much nicer to be able to treat the same rectangle as a 2D surface and let the infrastructure do whatever texture magic it needs to do |
| 11:38 | <gsnedders|work> | Hixie: Change the URLs :) |
| 11:38 | <Hixie> | done |
| 11:39 | <gsnedders|work> | I guess I ought to have had the g flag seeming there are multiple URLs :) |
| 11:53 | <sebmarkbage> | Hixie: I think I understand the issue Mozilla had with clientX, screenY positions of the "drag" and "dragend" events now. It's unclear what those attributes are relative to. Implicitly I would interpret that it's the current mouse position relative to the source node. But apparently there are alternative interpretations. |
| 11:55 | <annevk5> | client is relative to the viewport and screen relative to the screen iirc |
| 11:56 | <Hixie> | sebmarkbage: yeah we need a user interaction events specification to define this stuff |
| 11:57 | <sebmarkbage> | annevk5: yea, but which viewport if dragged across multiple windows? source or target? obviously it should be source, but it's undefined. |
| 11:58 | <hsivonen> | when a JS constructor/method takes an optional string argument, should null behave like no argument or like "null"? |
| 11:58 | <Hixie> | sebmarkbage: it should be relative to whatever viewport it is being dispatched to, imho |
| 11:58 | <hsivonen> | by convention? |
| 11:59 | <Hixie> | hsivonen: "null" |
| 11:59 | <Hixie> | by WebIDL |
| 11:59 | <hsivonen> | Hixie: thanks |
| 11:59 | <sebmarkbage> | Hixie: I agree. Which is the source viewport for "drag" and "dragend". |
| 12:00 | <Hixie> | sebmarkbage: ah, right |
| 12:01 | <hsivonen> | I intend to push an optional constructor argument for XMLSerializer in the Firefox 3.6 timeframe. Due to lack of feedback on public-webapps, I'm assuming this isn't a horribly bad idea. |
| 12:02 | <hsivonen> | the constructor argument is a MIME type for explicitly requesting particular serialization format |
| 12:02 | <hsivonen> | unknows default to XML |
| 12:02 | <hsivonen> | *unknowns |
| 12:02 | <Hixie> | you realise that if you're the last person to have touched XMLSerializer, you then officially own it and will be expected to write its spec, right |
| 12:02 | <hsivonen> | Hixie: Yes, I realize that. |
| 12:02 | <Hixie> | sweet |
| 12:02 | <Hixie> | we have a volunteer! |
| 12:03 | <Hixie> | that was easier than i expected |
| 12:04 | <othermaciej> | hsivonen: is XMLSerializer actually useful enough to be worth extending? |
| 12:04 | <hsivonen> | othermaciej: well, WebKit and MySpace compat are indicator suggesting Gecko's default behavior should change |
| 12:05 | <hsivonen> | othermaciej: but the current Gecko trunk behavior is useful, so the optional argument would allow that behavior to be requested |
| 12:05 | <hsivonen> | Is it a bad idea not to allow MIME type parameters? |
| 12:05 | <othermaciej> | the API is just kind of lame - the idea that you create an object just to call a single method that does the whole operation without needing an object for state is bogus |
| 12:06 | <hsivonen> | i.e. "text/html" is the same as "text/HTML" but "text/html; charset=foo" is different? |
| 12:06 | <hsivonen> | othermaciej: this introduces object state! |
| 12:06 | <othermaciej> | I guess I can see the use of forcing serialization as XML or HTML |
| 12:06 | <othermaciej> | hsivonen: yeah, but it's state that should be a parameter to the operation! |
| 12:07 | <hsivonen> | othermaciej: I don't think it's a given that it should be a parameter on the method |
| 12:07 | <othermaciej> | offering a MIME parameter also seems needlessly general |
| 12:07 | <othermaciej> | presumably HTML and XML are the only two formats actually on offer |
| 12:08 | <hsivonen> | othermaciej: currently yes, but I can foresee offering XHTML and SVG modes that are somehow nicer than generic XML in the future |
| 12:08 | <hsivonen> | Gecko already has distinct XML and XHTML serializers |
| 12:09 | <othermaciej> | WebKit always tries to be "nice" about serializing elements in the XHTML namespace as XML |
| 12:09 | <Lachy> | Hixie, for what exactly do we now have a volunteer? |
| 12:09 | <Hixie> | Lachy: i think hsivonen said he'd write the XMLSerializer spec |
| 12:10 | <othermaciej> | (i.e. make the markup HTML-compatible to the degree possible, for instance by only using minimized syntax for void elements) |
| 12:10 | <hsivonen> | Hixie: no, I said I realize I'm expected to if I touch XMLSerializer :-) |
| 12:10 | <Hixie> | :-) |
| 12:11 | <othermaciej> | I guess in Gecko internals, XMLSerializer has a stream interface in which case making it stateful is useful |
| 12:12 | <othermaciej> | but if I wanted a way to add forced XML and HTML serialization, without considering special Gecko needs, I would just add markupAsXML and markupAsHTML methods to Document and Element to go along with innerHTML |
| 12:12 | <othermaciej> | so you have a way to force either serialization that's just as convenient as getting the native serialization |
| 12:13 | <othermaciej> | saying new XMLSerializer("application/xml").serializeToString(doc) instead of doc.markupAsXML smells like Java to me |
| 12:14 | <hsivonen> | basically, with my patch, new XMLSerializer() creates a serializer that picks HTML vs. XML from the HTMLness flag on the document |
| 12:14 | <hsivonen> | new XMLSerializer("text/html") forces HTML |
| 12:14 | <hsivonen> | and new XMLSerializer("application/xml") forces XML |
| 12:15 | <Hixie> | well bummer |
| 12:15 | <Hixie> | html5 doesn't pass acid3. |
| 12:15 | <Hixie> | i suck. |
| 12:15 | <othermaciej> | I understand your proposal, I just think it's a bad API for that functionality |
| 12:15 | <hsivonen> | Hixie: 72? |
| 12:15 | <Hixie> | 71 |
| 12:15 | <hsivonen> | right |
| 12:15 | <hsivonen> | 72 was from memory |
| 12:15 | <gsnedders|work> | Wait, what… Currently XMLSerializer() returns HTML in HTML documents? |
| 12:15 | <hsivonen> | gsnedders|work: in shipped WebKit, yes |
| 12:16 | <hsivonen> | gsnedders|work: in shipped Opera and Firefox, it requires bogus stuff that's neither HTML nor XHTML |
| 12:16 | <Hixie> | three options |
| 12:16 | <Hixie> | i make acid3 allow uppercase or lowercase |
| 12:16 | <othermaciej> | I have to admit that was not really a considered decision |
| 12:16 | <Hixie> | i make html5 uppercase instead of lowercasing (bad for dom/xhtml consistency) |
| 12:16 | <gsnedders|work> | Hixie: It's HTML 4.01, so I'd make it case insensitive |
| 12:16 | <Hixie> | i make html5 case-sensitive |
| 12:17 | <gsnedders|work> | s/it c/acid3 c/ |
| 12:17 | <Hixie> | i'm leaning towards making acid3 case-insensitive, yeah |
| 12:17 | <hsivonen> | othermaciej: would you change it knowing that changing it would break a MySpace feature unless MySpace changes their JS? |
| 12:17 | <othermaciej> | hsivonen: the real web compat requirement is not having namespace declarations, right? |
| 12:17 | <hsivonen> | othermaciej: yes |
| 12:17 | <annevk5> | hsivonen, can we make it simpler than media types? |
| 12:18 | <hsivonen> | annevk5: IDL constants are more complex |
| 12:18 | <othermaciej> | I would consider text/html to be a less bogus choice than XML with HTML elements moved to the null namespace |
| 12:18 | <hsivonen> | annevk5: I could make it "html" |
| 12:18 | <othermaciej> | if those are the only two choices |
| 12:18 | <annevk5> | hsivonen, we could just have "xml" and "html" |
| 12:18 | <othermaciej> | annevk5: I think it should just be two methods on Document/Element |
| 12:18 | <othermaciej> | like I said |
| 12:18 | <othermaciej> | doc.markupAsXML |
| 12:18 | <othermaciej> | vs |
| 12:18 | <othermaciej> | XMLSerializer("application/xml").serializeToString(doc) |
| 12:19 | <annevk5> | doc.innerHTML ? |
| 12:19 | <annevk5> | doc.innerHTML depends on the HTMLness/XMLness of a Document |
| 12:19 | <othermaciej> | innerHTML unfortunately has to mean "serialize as this document's format" which I guess is what XMLSerializer has to do, if we can't convince myspace to change |
| 12:20 | <othermaciej> | I'm saying two new properties similar to innerHTML would be a nicer API than two new modes for XMLSerializer |
| 12:20 | <othermaciej> | easier to feature test for, too |
| 12:20 | <hsivonen> | I wouldn't be at all surprised if it wasn't just MySpace running naive regexps over XMLSerializer output |
| 12:20 | <hsivonen> | the feature testing argument makes sense |
| 12:21 | <hsivonen> | hmm. zcorpan isn't here |
| 12:21 | <hsivonen> | zcorpan owns Document and Element now, right? |
| 12:21 | <othermaciej> | an equally feature-testable approach would be to add two new methods to XMLSerializer, but I still think that is needlessly complex |
| 12:22 | <annevk5> | fair enough |
| 12:22 | <annevk5> | is it defined how to serialize SVG subtrees within HTML btw? |
| 12:23 | <hsivonen> | I'm not sure. It will need to get defined in detail. |
| 12:23 | <Hixie> | hsivonen: fixed acid3 |
| 12:23 | <hsivonen> | Hixie: thanks |
| 12:23 | <Hixie> | added http://acid3.acidtests.org/acid3-2009-08-13.tar.gz for those of you who use acid3 tarballs |
| 12:24 | <hsivonen> | Hixie: I still get Test 71 failed: doc.open is not a function |
| 12:24 | <hsivonen> | Hixie: could very well be my bug |
| 12:25 | <Hixie> | hsivonen: firefox passes test 71 for me, so, that seems like your bug. |
| 12:28 | <hsivonen> | Hixie: with what value of html5.enable? |
| 12:28 | <Hixie> | true |
| 12:28 | <hsivonen> | oh. interesting! |
| 12:29 | <Hixie> | wait, you thought i had it set to false? |
| 12:29 | <Hixie> | i live on the edge! |
| 12:29 | <hsivonen> | :-) |
| 12:29 | <Hixie> | only luddites would have html5.enable set to false! |
| 12:32 | <othermaciej> | clearly we need to add an EnableHTML5 hidden pref to Safari, and make it not do anything |
| 12:33 | <annevk5> | hah, you'd have to fix some parser bugs first! |
| 12:34 | <gsnedders|work> | Hixie: Are you a luddit even if your just checking whether the old parser has a bug? |
| 12:34 | <gsnedders|work> | *you're |
| 12:34 | <Hixie> | gsnedders|work: nah, then you're just living in the past |
| 12:34 | gsnedders|work | stabs self for that mistake (with a plastic knife, again) |
| 12:41 | <jgraham> | without knowing what XMLSerializer does, exactly, I would make the API something like document.toString([type]) where type = "html"|"xml" |
| 12:43 | <jgraham> | (I understand that this is not backward compatible) |
| 12:47 | <hsivonen> | basically, I want to accomplish the following: |
| 12:47 | <hsivonen> | 1) Make XMLSerializer applied to HTML docs compatible with WebKit |
| 12:48 | <hsivonen> | 2) Have an API that people won't be too unhappy with in the future for serializing HTML docs/subtrees as namespace-correct XML |
| 12:48 | <hsivonen> | 3) Do this in the Gecko 1.9.2 timeframe |
| 12:49 | <Mrmil> | Hi, I have a little offtopic question: I heard that <input type="file"> is not stylable for security purposes. Can anyone tell me an example of such abuse? :) |
| 12:50 | <hsivonen> | 4) I don't want to make unilateralist Browser Wars -type actions. |
| 12:59 | <Lachy> | Mrmil, http://lachy.id.au/dev/markup/examples/forms/file/ |
| 13:00 | <Lachy> | Mrmil, those demos worked in older versions of Firefox. They've since made it more difficult though, since you can't type directly into the control any more |
| 13:02 | <Mrmil> | Lachy: Ok, thanks, will check it out |
| 13:06 | <Mrmil> | Lachy: it reminds me of clickjacking a little bit |
| 13:10 | <Hixie> | nn |
| 13:13 | <sebmarkbage> | Hixie: About separating copy/paste and drag/drop. I think we missunderstand eachother. I'm asking for the current copy/paste model to be replaced with what's already implemented in WebKit (which is also similar to IE). |
| 13:18 | <sebmarkbage> | The distinction is that it's valid for data in a copy/paste operation to live for a long time, while in a drag/drop operation the data can be considered invalid after dragend. It has nothing to do with whether or not the code supports multiple apps or not. |
| 13:21 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=505783 xml:base is actually being used from script |
| 14:14 | <hsivonen> | http://lists.xml.org/archives/xml-dev/200908/maillist.html Namespaces seem to dominate the discussion |
| 14:15 | <hsivonen> | http://lists.xml.org/archives/xml-dev/200907/msg00157.html |
| 14:22 | <Lachy> | I don't see how that's much of an improvement over xmlns, since his using.foo="" attributes create just as much of an abstraction as xmlns:foo does, just with a slightly different syntax and processing rules |
| 14:23 | <Lachy> | but the idea of using elements like <com.example.foo> is intriguing and possibly worth further investigation |
| 14:24 | jgraham | bets that it has compat issues |
| 14:24 | <jgraham> | Although maybe it would be OK as long as people are using namespace-unaware APIs |
| 14:25 | <Lachy> | it has compat issues where he suggests document.getElementsByTagName("id") would match an element like <com.example.id> |
| 14:25 | <jgraham> | Oh yeah, that wouldn't work |
| 14:26 | <hsivonen> | I think I'm going to reply, although I'm afraid I'll get sucked into more debate than I want to get sucked into |
| 14:30 | <Lachy> | it's not clear whether he's suggesting the syntax should work in XML too, thus providing a complete alternative to xmlns, or whether it would just apply to HTML |
| 14:48 | <annevk42> | I kind of like nl.annevankesteren.example |
| 14:48 | <annevk42> | as element and attribute namespacing-style |
| 14:52 | <annevk42> | hmm, apparently the On2 takeover is under attack |
| 14:56 | <Philip`> | Someone should register the domain stom.cu, for use in reverse-DNS custom names |
| 14:57 | <Dashiva> | Philip`: Why aren't you doing it yourself? |
| 14:58 | <Philip`> | Because I assume it costs money |
| 14:59 | <Dashiva> | You can make that back by selling the rights to <somename>.stom.cu |
| 15:00 | <annevk42> | it's not available |
| 15:00 | <Philip`> | US$1150/year, apparently |
| 15:00 | <annevk42> | that too |
| 15:00 | <Lachy> | charge roylaties for people using cu.stom.elements in their vocabularies :-) |
| 15:00 | <Philip`> | annevk42: According to something like http://www.marcaria.com/register/domain/domain_registration.asp?country=Cuba ? |
| 15:00 | <Lachy> | woah, why would a .cu TLD be that costly? |
| 15:00 | <Philip`> | That says lkjfxhgklejhxgkljh.cu is not available either |
| 15:00 | <Dashiva> | I suppose expecting a four-letter name to be free is naive? |
| 15:01 | <annevk42> | Philip`, ah ok |
| 15:04 | <Philip`> | "I'm using <progress> right now to indicate how far someone is in providing translations for our program. I'm waiting for browsers to catch up and actually display the element, but in the meantime the fallback content is fine." - oh no, legacy content before the feature even exists :-( |
| 15:04 | <Lachy> | annevk42, do you have a reference regarding the On2 takeover being under attack? |
| 15:05 | <annevk42> | a Dutch one |
| 15:05 | <annevk42> | apparently the stockholders of On2 are not satisfied |
| 15:05 | <smedero> | in english: http://news.cnet.com/8301-1023_3-10308834-93.html |
| 15:06 | <Philip`> | Sounds like haggling over the price |
| 15:07 | <Dashiva> | Sounds like something everyone should've seen coming |
| 15:07 | <Dashiva> | (Well, those involved in the deal) |
| 15:09 | <Philip`> | The shareholders would be a bit silly if they didn't try to squeeze as much money out of Google as they could |
| 15:10 | <Lachy> | the amount being offered is already "a 57 percent premium over On2's closing stock price on the last trading day before the announcement", and it's absurd to think receiving 157% of the company's value is too low |
| 15:11 | <annevk42> | apparently not |
| 15:11 | <Dashiva> | Well, the article also mentions it was trading much above that not long ago |
| 15:11 | <Dashiva> | Stock prices do bounce |
| 15:13 | <Lachy> | the article doesn't say whether that was just a spike in the stock price or whether it normally trades steadily around that price |
| 15:14 | <Dashiva> | The people who control the release of the announcement have a high interest in as low a price as possible, so it'd seem likely they'd time it for a low |
| 15:14 | Lachy | tries to get a graph from google finance |
| 15:14 | <smedero> | http://www.google.com/finance?chdnp=1&chdd=1&chds=1&chdv=1&chvs=maximized&chdeh=0&chdet=1244664000000&chddm=242823&chls=IntervalBasedLine&q=AMEX:ONT&ntsp=0 |
| 15:14 | <Lachy> | oh, thanks smedero |
| 15:14 | <smedero> | (2007 to June 2009) |
| 15:16 | <Lachy> | so it's been on its way down since 2007, with little sign of it starting to suddenly increase |
| 15:16 | <Philip`> | With that kind of insight, you could make millions on the stock market |
| 15:17 | <Lachy> | :-D |
| 15:18 | <Lachy> | oh, it was at $29 back in 2000. It's only a matter of time before it gets back up there. The shareholders should demand that much! |
| 15:28 | <Lachy> | http://dev.w3.org/html5/pf-summary/tabular-data.html#attr-table-summary |
| 15:30 | <Dashiva> | How appropriate, the summary description is so dense as to require a summary :) |
| 15:34 | <Philip`> | That version also adds table.summary, table.createSummary(), table.deleteSummary() |
| 15:35 | <Dashiva> | Yeah, the latter two are probably just bad copypasting of the element-specific methods |
| 15:35 | <Dashiva> | (Not that I've seen anyone use create/delete table methods in the first place) |
| 15:37 | <Lachy> | Dashiva, it doesn't help that not only is it one excessively long paragraph, the line-height used in that copy of the spec is too low. The whatwg copy uses line-height: 1.35, which is much more legible. |
| 15:42 | <Dashiva> | I'm starting to understand what they mean about "inaccessible to people with cognitive disabilities" |
| 16:24 | <annevk42> | http://twitter.com/collinjackson/status/3287780034 is funny |
| 16:38 | <Philip`> | "That page doesn't exist!" - hilarious |
| 16:39 | <smedero> | perhaps: http://twitter.com/collinjackson/status/3287900575 |
| 16:39 | <annevk42> | yeah |
| 16:39 | <annevk42> | he made some small change I suppose |
| 16:41 | <Dashiva> | What happened to cool URIs do not change |
| 16:46 | <smedero> | It is coolness factor was not high enough to trigger immutability |
| 16:46 | <smedero> | s/it is/its/ |
| 16:58 | <Philip`> | "< Dashiva> (Not that I've seen anyone use create/delete table methods in the first place)" - I was going to say "here's a zillion pages that rely on those methods", but actually I grepped for (create|delete)(Caption|THead|TFoot|TBody) and found zero :-( |
| 16:59 | <Dashiva> | Yeah |
| 16:59 | <Dashiva> | I didn't even know they existed until I read the webapps spec for <table> |
| 17:23 | <annevk42> | and it continues: http://twitter.com/collinjackson/status/3288471855 |
| 17:25 | Philip` | gets that message all the time |
| 17:25 | <Philip`> | Actually I have it right now, on https://mail.google.com |
| 17:40 | <Lachy> | annevk42, in your survey response, you wrote: "In general I'm ok with publishing all Editor's Draft that have majority approval, but they have to offer *some non-normative difference* in my opinion." (emphasis added) |
| 17:40 | <Lachy> | don't you mean they have to offer some *normative* difference? |
| 17:43 | <annevk42> | doh |
| 19:01 | <annevk42> | oh yes, I'm on ietf-charsets now |
| 19:02 | <annevk42> | I guess I should ask a question on how to register an alias now given that there's no official thingie for that |
| 19:24 | <annevk42> | Hixie, http://mail.apps.ietf.org/ietf/charsets/msg01830.html |
| 19:25 | annevk42 | eagerly awaits the first email pointing out it is completely impossible ever to register anything with a "x-" prefix and that the remaining one looks dodgy |
| 19:33 | annevk42 | also subscribed to http-state for good measure |
| 19:39 | Lachy | subscribed to ietf-charsets to track the issue |
| 19:41 | <Lachy> | Hixie, Would it be possible for you to publish a full, non-split version of HTML5 that includes all of web workers, web storage/database, etc? Reading those split out specs is annoying since so many of the references to HTML5 aren't linked. |
| 19:44 | <Philip`> | Lachy: You could write the code to handle cross-spec cross-referencs :-) |
| 19:46 | <hsivonen> | I replied on xml-dev: http://lists.xml.org/archives/xml-dev/200908/msg00203.html |
| 19:47 | <Lachy> | Philip`, that doesn't solve the other problem of me having to keep more than one spec open, thus using up more than one tab |
| 19:52 | hsivonen | doesn't really understand why shareholders can sue in this case |
| 19:52 | hsivonen | thought shareholders got to vote in situations like this, and that's it. Sucks to be a minority shareholder. |
| 19:53 | <hsivonen> | Kinda sucks to be a publicly held company, too, sometimes. |
| 20:51 | <jgraham> | Hixie: I just broke pimpmyspec doing an upgrade. Sorry |
| 20:52 | <jgraham> | Oh wait, I think I just gave it invalid input |
| 20:53 | <jgraham> | It seems to work |
| 21:00 | <Hixie> | annevk42: nice. note the long list of other aliases that we need to register that aren't in teh spec yet, though |
| 21:00 | <Hixie> | Lachy: i haven't been maintaining the source in a way that would make that pretty |
| 21:02 | <gsnedders> | jgraham: Upgrade = applying patch from me? |
| 21:02 | <jgraham> | gsnedders: Yes |
| 21:02 | <gsnedders> | Oh, I guess I should tell you now you've done it that I didn't test it or anything :P |
| 21:03 | <hsivonen> | Hixie: did you notice the namespace thread on xml-dev? |
| 21:03 | <Hixie> | uri? |
| 21:03 | <Hixie> | (i'm not on xml-dev) |
| 21:03 | <hsivonen> | my reply: http://lists.xml.org/archives/xml-dev/200908/msg00203.html |
| 21:04 | <hsivonen> | the email I replied to: http://lists.xml.org/archives/xml-dev/200907/msg00157.html |
| 21:06 | <annevk42> | Hixie, you mean once we update the spec to no longer use the Unicode matching algorithm? |
| 21:06 | <annevk42> | Hixie, or some other list I've missed? |
| 21:06 | <annevk42> | Hixie, in any case, once I figure out how this works that should be no problem :) |
| 21:06 | <Hixie> | annevk42: some other list you've missed |
| 21:07 | <Hixie> | i'll get you a link in a few minutes |
| 21:07 | <othermaciej_> | Hixie: today's telecon was actually marginally useful |
| 21:07 | <othermaciej_> | (it hurts me to type that) |
| 21:09 | <Hixie> | othermaciej: you mean it allowed you to communicate with people who seem only able to make progress holding a telephone to their ear? |
| 21:10 | <othermaciej> | Hixie: indeed, I believe I successfully served as Speaker-to-Telephone-Users |
| 21:11 | <othermaciej> | Hixie: I think they didn't actually understand the issue, and for some reason hearing the examples of role conflicting with native semantics out loud helped them |
| 21:11 | <othermaciej> | otoh, "most useful 15 minutes of telecon time ever" is a pretty low bar |
| 21:12 | <annevk42> | Hixie, other than the list that says ISO-8859-1 must be treated as windows-1252 I cannot find anything |
| 21:12 | <annevk42> | Hixie, within HTML5, that is |
| 21:13 | <Hixie> | annevk42: yeah hold on i have like 18 things going on here |
| 21:15 | <annevk42> | hmm, my mind shifts to wondering how I can cause some overflow exception to occur :evil: |
| 21:17 | <Hixie> | annevk42: http://www.mail-archive.com/whatwg⊙lwo/msg16301.html |
| 21:20 | <annevk42> | ah crap |
| 21:20 | <annevk42> | that also involved toally new encodings |
| 21:21 | <annevk42> | such as a bunch of legacy Mac encodings |
| 21:21 | <Hixie> | i wouldn't worry about all of them necessarily |
| 21:21 | <Hixie> | especially if IE doesn't do them |
| 21:21 | <annevk42> | all browsers support them |
| 21:23 | <annevk42> | solving the whole problem seems like a daunting task |
| 21:25 | <annevk42> | based on a 4M data set it appears these Mac encodings are actually used too |
| 21:26 | <Hixie> | there's a reason i shied away :-) |
| 21:27 | <hsivonen> | :-( sending legacy mac encoding to a public network sucks |
| 21:28 | <Hixie> | annevk42: oh man i totally forgot to remind you about the podcast idea, thanks for remembering |
| 21:30 | <Hixie> | hsivonen: interesting proposal, though it seems to suffer from the lack of graceful degradation |
| 21:31 | <annevk42> | 1) we need a list of encoding names required for web compat 2) we need documentation that gives you the canonicalized encoding name for a given encoding name 3) we need a mapping to Unicode for a given byte stream + canonicalized encoding name 4) we need a mapping from Unicode + a canonicalized encoding name to a byte stream |
| 21:31 | <Hixie> | hsivonen: it seems like a slight improvement would be <x class="com.example.y"> instead of <com.example.y>, where "x" is the closest corresponding HTML element |
| 21:31 | <annevk42> | the outcome is not profit, so not sure how to motivate people here :) |
| 21:32 | <Hixie> | i'm all out of time, otherwise i'd be all over this |
| 21:34 | <Hixie> | was someone asking me about the spec splitter script i use at some point? |
| 21:34 | <Hixie> | something about regexps or something |
| 21:37 | <gsnedders> | Hixie: Myself and jgraham were talking about it at work… |
| 21:38 | <Hixie> | i must be psychic |
| 21:43 | <gsnedders> | I can't remember why we were discussion it, but the conclusion was it would probably be easiest and best to ask you for your script rather than write our own |
| 21:43 | <gsnedders> | *discussing |
| 21:45 | <virtuelv> | document.write("<base href='"+some_url+"'>"); |
| 21:45 | <Hixie> | gsnedders: ah. i can send you the script if you want, but it won't help you much (it's quite dependent on the setup i have here) |
| 21:45 | <virtuelv> | is the behavior specified somewhere in HTML5? |
| 21:45 | <jgraham> | Hixie: Yeah it would be nice to know how you process the spec. ATM I am just making some very simple assumptions about the use of start and end markers |
| 21:45 | <Hixie> | virtuelv: yes |
| 21:45 | <Hixie> | jgraham⊙oc? |
| 21:45 | <virtuelv> | Hixie: I assume it does set it? |
| 21:46 | <Hixie> | and gsnedders⊙oc? |
| 21:46 | <gsnedders> | Sadly not :( |
| 21:46 | <jgraham> | Hixie: Sure |
| 21:46 | <jgraham> | Thanks |
| 21:46 | <gsnedders> | gsneddon |
| 21:46 | <Hixie> | virtuelv: it's relatively complicated, but yes, more or less |
| 21:46 | gsnedders | would much rather have gsnedders, as it keeps confusing people :( |
| 21:46 | <virtuelv> | Hixie: and it gets more complicated with opera's "delayed script execution" setting |
| 21:50 | <Hixie> | gsnedders, jgraham: sent. it's a work in progress, though, so it might change tomorrow, say |
| 21:50 | <Hixie> | the <!--START xxx--> markers in particular changed semantics completely a few weeks ago |
| 21:50 | <Lachy> | hsivonen, regarding that pragmatic namespace thread, I had a thought about the getElementsByTagName() issue that couldn't work for back compat issues... |
| 21:50 | <gsnedders> | Hixie: Is there any reason why the whole script gen toolchain isn't in SVN? |
| 21:51 | <jgraham> | Hixie: Thanks |
| 21:52 | <Lachy> | hsivonen, it's possible, if the idea of using custom elements like <com.example.foo> works out, it might be possible to introduce a new Selector that could be used with Selectors API, conceputally like querySelector("???.foo") |
| 21:53 | <Hixie> | gsnedders: it contains passwords and stuff, and is so tied to my local setup that i really don't see the point |
| 21:53 | <hsivonen> | Lachy: I'd expect the perf of such a selector to be bad |
| 21:54 | <Lachy> | yeah, I thought that might be an issue too, but I'm not sure |
| 21:54 | <hsivonen> | at least if DOM implementation internals aren't changed |
| 21:55 | <Lachy> | yeah, it may need some DOM internals to be changed, so that the browser somehow remembers the last segment of the tag name and just matches against that, rather than trying to do a partial string match against the whole element |
| 21:57 | <Lachy> | although, to be honest, having to do getElementsByTagName("com.example.foo") isn't so bad, especially if it can be combined with JS libraries that take shorten it a bit |
| 21:58 | <Philip`> | var com_example = { 'foo': 'com.example.foo' |
| 21:58 | <Philip`> | (Oops, silly enter key) |
| 21:58 | <Philip`> | var com_example = { 'foo': 'com.example.foo' } ... with (com_example) getElementsByTagName(foo) |
| 21:58 | <Philip`> | That's nice and short :-) |
| 21:59 | <jgraham> | Die with statement, die |
| 21:59 | <Philip`> | Oh, actually you could do var com = { 'example': { 'foo': 'com.example.foo' }} ... with (com.example) getElementsByTagName(foo) and then it's even shorter |
| 21:59 | <Philip`> | Wait, not shorter |
| 21:59 | <Philip`> | Longer |
| 21:59 | <Philip`> | but with prettier symbols |
| 22:00 | <Lachy> | Philip`, I was thinking some kind of wrapper function like function xxx(tagName) { document.getElementsByTagName("com.example." + tagName); } xxx(foo); |
| 22:01 | <Philip`> | Would 'with' be much less problematic if it was like "with (foo) { .bar == foo.bar }" (instead of "bar == foo.bar"), like in VB, since it would let you identify variable accesses that need to care about the with? |
| 22:01 | <Lachy> | er, I mean: xxx("foo"); |
| 22:01 | <Dashiva> | Please let's not encourage use of with |
| 22:02 | <Philip`> | It's a solution to all problems! |
| 22:02 | <Lachy> | Dashiva, should we stop using "with" in english too? |
| 22:02 | <jgraham> | Philip`: I guess that would help |
| 22:02 | <Dashiva> | Lachy: Only if it refers to the with statement |
| 22:03 | <Lachy> | Dashiva, you just broke the rule |
| 22:03 | <Dashiva> | No, it's only a 'should' |
| 22:03 | <Dashiva> | I had a good reason to break it :P |
| 22:04 | <Dashiva> | Seriously, though, with is headed for the scrap heap of history |
| 22:05 | <Philip`> | On the web, the scrap heap is kept in the living room |
| 22:05 | <jgraham> | http://hoppipolla.co.uk/410/spec-full.html |
| 22:05 | <Philip`> | Uh, that's a terrible metaphor |
| 22:05 | <jgraham> | http://hoppipolla.co.uk/410/spec-author.html |
| 22:05 | <Lachy> | What are the reasons to avoid two-way normative references? Is it just a problem with the process that causes hold ups in spec development, or is there some real technical reason for it that actually affects the content of the spec? |
| 22:05 | <Philip`> | but anyway I guess I mean we're stuck with it |
| 22:06 | <Dashiva> | Philip`: It's an error in strict mode |
| 22:06 | <jgraham> | Like yesterday's jam |
| 22:06 | <Dashiva> | But we can't stop kids from playing in the heap, no |
| 22:06 | <jgraham> | Dashiva: No one implements that yet |
| 22:06 | <othermaciej> | Lachy: I don't think there is a technical reason, it's just that if both sides of the xref are new, the specs can only be at most one step apart on the standards track |
| 22:06 | <othermaciej> | (where WD, CR, PR are the relevant states I think...) |
| 22:06 | <Dashiva> | jgraham: They will by the time the cloud castles discussed here are implemented :) |
| 22:06 | <Lachy> | right, so it's a problem with the process |
| 22:07 | <Lachy> | Shouldn't we fix the process? |
| 22:07 | <othermaciej> | I wouldn't say that kind of rule is a *problem* |
| 22:07 | <othermaciej> | it doesn't make sense to make something a frozen REC with an unstable normative reference |
| 22:07 | <jgraham> | Lachy: Presumably it makes conflicts or underdefinition more likely |
| 22:07 | <Philip`> | We should fix the process so there's no need to split it into a separate spec (since process issues and LC feature freezes were the reason to propose splitting it) |
| 22:08 | <Philip`> | if we try to fix the process at all |
| 22:08 | <Lachy> | Philip`, good point |
| 22:08 | <Philip`> | maybe |
| 22:08 | <othermaciej> | I think splitting out canvas is not a worthwhile way to spend our time at this point anyway, so I don't think we need to worry about the best way to do it in theory |
| 22:08 | <Lachy> | there was also the reason that people thought it would be better if the API were developed by a more graphically oriented group than HTML |
| 22:09 | <othermaciej> | unless one of you wants to volunteer to edit the split spec and can have it WD-ready in like a month or so |
| 22:10 | <Lachy> | Shelley volunteered. Not sure how good she'd be as an editor, but she's welcome to try and put forth a proposal, at which point we can evaluate it and then decide how to proceed |
| 22:11 | <othermaciej> | it seems to me she volunteered to be declared editor with other co-editors in a newly created Working Group |
| 22:12 | <othermaciej> | I did not see where she volunteered to write some quality spec text in a timely manner or maintain it as needed |
| 22:12 | <Lachy> | Personally, I don't really care if we split it or not |
| 22:12 | <othermaciej> | me neither, I'd just rather not spend a lot of time discussing it until someone steps up and does a passable initial attempt |