| 00:41 | <annevk> | hmm, https://datatracker.ietf.org/ipr/942/ |
| 00:43 | <andersca_> | Hixie: got a q about the ApplicationCache interface |
| 00:44 | <Hixie> | shot |
| 00:44 | <Hixie> | shoot even |
| 00:44 | <andersca_> | about the item method |
| 00:44 | <andersca_> | "The item(index) method must return the dynamic entries with index index from the application cache, if one is associated with the ApplicationCache object." |
| 00:44 | <andersca_> | what does it return? the URL? |
| 00:45 | <Hixie> | please hold |
| 00:45 | andersca | holds |
| 00:46 | <Hixie> | yeah, url. that's not clear. send mail? |
| 00:49 | <andersca> | will do |
| 00:49 | <andersca> | Hixie: thanks! |
| 00:49 | <andersca> | Hixie: I was pretty sure that it was URL but I figured it never hurts if the spec is clear on what it is >( |
| 00:49 | <andersca> | :) even |
| 00:50 | <Hixie> | yeah |
| 00:50 | <Hixie> | i dunno why i left it so vague |
| 00:50 | <Hixie> | that's terrible |
| 00:50 | <Hixie> | i guess it is just a first draft :-) |
| 00:52 | <annevk> | hmm, someone needs to repost the "cookie" issue indeed |
| 00:52 | annevk | thought it was a non-issue |
| 00:53 | <Hixie> | i don't understand what the issue _is_ exactly |
| 00:53 | <Hixie> | though i agree there's an issue |
| 00:54 | <Hixie> | without really understanding what the issue is, though, i can't easily fix the spec |
| 00:54 | <Hixie> | or rather, propose fixes to the spec, since i'm not the editor of that one :-) |
| 00:57 | <othermaciej_> | I think the issue is fear |
| 00:57 | <othermaciej_> | and I am not saying that to be demeaning |
| 00:57 | <othermaciej_> | fear when exposing new network capabilities to web content is very healthy |
| 00:57 | <Hixie> | i don't exactly understand the fear, so it's not clear to me how to resolve it |
| 00:58 | <Hixie> | it seems like there are as many reasons to send cookies as to not send cookies, and that there is fear in both directions |
| 00:58 | <Hixie> | so we need to clearly look at what the various fears _are_, and work out how to mitigate them |
| 00:58 | <Hixie> | while still addressing all the important use cases |
| 01:01 | <othermaciej_> | are some of the Mozilla people most interested in this local to the bay area? perhaps this is the sort of issue where informal chat in person + whiteboard could crystallize a lot of the issues |
| 01:07 | <Hixie> | i'd very open to attending any meeting on a specific issue around here if someone wants to organise it |
| 01:08 | <othermaciej> | I don't know who the relevant mozilla people are |
| 01:08 | <othermaciej> | I guess I can ask sicking |
| 01:20 | <gavin_> | othermaciej_: dveditz, jruderman, sicking at least |
| 01:21 | <gavin_> | all @mozilla.com for email (and IRC) |
| 01:22 | <jruderman> | you also want window, who i think was the one arguing most strongly for not sending cookies (or postponing support until we're more sure that it's safe) |
| 01:23 | <jruderman> | we're all local to the bay area |
| 01:25 | <jruderman> | shaver might be interested. he's not local but he's visiting mountain view this week. |
| 01:27 | <jruderman> | window's schedule is probably the most constrained |
| 01:28 | <othermaciej_> | I'll see what I can do |
| 01:28 | <othermaciej_> | some of Apple's security guys may be interested |
| 01:28 | <jruderman> | a guy from HP, tyler close, came to the meeting at mozilla a month or so ago |
| 01:50 | Hixie | finally gets around to reading the day's math stuff |
| 01:50 | <Hixie> | people seem to massively underestimate the cost of 140 new elements in the parser |
| 01:51 | <Hixie> | especially given that they want all 140 of those elements to be ignored... |
| 01:53 | <Hixie> | william's proposed syntax isn't too bad |
| 01:56 | <Hixie> | hsivonen: embedded content mathml is more like longdesc than external download links for content mathml -- those would be more like [D] links |
| 03:58 | <Hixie> | man i wish more specs did what html5 does with having both the content model _and_ the expected parents right by the element definition |
| 03:58 | <Hixie> | trying to work out where <svg:a> is allowed is non-trivial |
| 04:12 | <shepazu> | Hixie: it should be possible to modify this table to also show expected parents: http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/elementTable.html |
| 04:12 | <shepazu> | I can look into that if you think it would be useful |
| 04:18 | Phrogz | is not a fan of the way the dl/dt/dd (I assume) is used without CSS at the top of that page; Safari makes it hard to tell which descriptions go with which icons for sure. |
| 04:18 | <Phrogz> | (As a random aside.) |
| 04:19 | <Phrogz> | Suggest either dd { margin-bottom:1em } or dt { float:left; width:4em; clear:left } dd { margin-left:5em } blah blah blah |
| 06:30 | <Hixie> | shepazu: that would be useful; do you have that for the svg1.1 elements too? |
| 06:31 | <shepazu> | Hixie: I don't recall, but if not, we could produce it for the errata, perhaps... what time frame would be useful? |
| 06:31 | <Hixie> | before friday? :-) |
| 06:31 | <shepazu> | (that is, can't promise it would be done quickly) |
| 06:31 | <shepazu> | ohhhh |
| 06:31 | <shepazu> | well..... :) |
| 06:31 | <shepazu> | I can see if we already have one |
| 06:31 | <shepazu> | I'll get back to you on that tomorrow |
| 06:31 | <Hixie> | if you don't have anything don't worry, it's not a huge deal, i can just derive it manually |
| 06:32 | <shepazu> | I agree that it should be done |
| 06:32 | <shepazu> | that would be very handy for authors |
| 06:32 | <Hixie> | yeah |
| 06:32 | <Hixie> | makes it much easier to walk up and down the schema while reading the spec |
| 08:37 | <hsivonen> | Hixie: better wish that content model and expected parent are reciprocal in the spec... I've read one where they weren't |
| 08:38 | <Hixie> | uh |
| 08:38 | <Hixie> | that would be exciting |
| 11:42 | <annevk> | ~/ |
| 12:27 | <hsivonen> | hmm. I have some weird reset insertion mode code for th and td |
| 12:27 | <hsivonen> | that makes a test fail |
| 12:27 | <hsivonen> | but that code cannot be there by accident |
| 12:31 | <hsivonen> | ok, I'm just impementing the spec... |
| 12:33 | <hsivonen> | Why does this: |
| 12:33 | <hsivonen> | #data |
| 12:33 | <hsivonen> | </table></tbody></tfoot></thead></tr><div> |
| 12:33 | <hsivonen> | #document-fragment |
| 12:33 | <hsivonen> | td |
| 12:33 | <hsivonen> | expect this |
| 12:33 | <hsivonen> | #document |
| 12:33 | <hsivonen> | | <div> |
| 12:33 | <hsivonen> | Given step #3 in "reset the insertion mode"? |
| 12:34 | <hsivonen> | step 3 being If node is the first node in the stack of open elements, then set last to true; if, in addition, the context element of the HTML fragment parsing algorithm is neither a td element nor a th element, then set node to the context element. |
| 12:39 | <hsivonen> | svn blame blames ryansking |
| 12:39 | <annevk> | what else would make sense? |
| 12:40 | <annevk> | (i haven't tried reading the spec for this though) |
| 12:40 | <hsivonen> | | <head> |
| 12:40 | <hsivonen> | | <body> |
| 12:40 | <hsivonen> | | <div> |
| 12:40 | <hsivonen> | per spec |
| 12:40 | <hsivonen> | not necessarily making sense, though |
| 12:41 | <hsivonen> | but step 3 in the spec sure look deliberate |
| 12:41 | <hsivonen> | looks |
| 12:41 | <annevk> | isn't there some rule that scopes it to <body>? |
| 12:42 | <hsivonen> | step 15? |
| 12:45 | <hsivonen> | looks like I'm missing the 'last' flag |
| 12:47 | <hsivonen> | hmm. nope, step 15 is not it |
| 13:00 | <annevk> | i'll take a look |
| 13:00 | <annevk> | having said that, i'm jetlagged |
| 13:02 | <annevk> | hsivonen, so it seems that from step 3 you end up at step 5 |
| 13:04 | <hsivonen> | annevk: nope. 'node' is "html" at step 5 |
| 13:05 | <hsivonen> | because it specifically did *not* get set to "td" in step 3 |
| 13:08 | <annevk> | hmm, yeah, weird |
| 13:08 | <virtuelv> | hmph |
| 13:08 | <virtuelv> | ISO approved OOXML </offtopic> |
| 13:09 | <annevk> | yeah... |
| 13:11 | <hsivonen> | the OOXML "process" stinks |
| 13:11 | <hsivonen> | pretending that it is a voting process and then carrying it out like that sucks |
| 13:12 | <hsivonen> | also, the technical correction process was a bad joke |
| 13:12 | <hsivonen> | because it's unreasonable to try to fix a spec of that size at that point with that schedule |
| 13:13 | <hsivonen> | and it's also unreasonable to ask the whole world to engage in barn-raising and fixing the spec |
| 13:15 | <virtuelv> | personally, I see this as yet another nail in the coffin for desktop-centric document formats |
| 13:15 | <hsivonen> | personally, I'd prefer ODF rewritten in the "5" style with proper processing requirements |
| 13:16 | <virtuelv> | why not HTML instead? |
| 13:16 | <hsivonen> | I wouldn't be surprised if ODF5 would be the size of OOXML or larger |
| 13:16 | <hsivonen> | in pages |
| 13:17 | <hsivonen> | virtuelv: HTML has a different level of abstraction compared to a spreadsheet |
| 13:17 | <hsivonen> | virtuelv: so supporting spreadsheet round-tripping would invoke things that Hixie thinks are anti-patterns |
| 13:18 | <virtuelv> | yes, but for presentations and text-like documents, plain HTML suffices |
| 13:18 | <virtuelv> | my point is still that I think these should be transparent web formats |
| 13:19 | <webben> | well ODF could be served over the web |
| 13:19 | <webben> | it's just another format |
| 13:19 | <webben> | IIRC there is or was a Firefox addon to read ODF. |
| 13:19 | <webben> | https://addons.mozilla.org/en-US/firefox/addon/1888 |
| 13:19 | <hsivonen> | webben: ODF is not streamable over HTTP |
| 13:19 | <webben> | hsivonen: You mean no progressive load? |
| 13:20 | <hsivonen> | webben: yes |
| 13:20 | <webben> | Well, progressive load is a nice to have. Not sure it's crucial though. |
| 13:21 | <hsivonen> | virtuelv: HTML plus CSS is too powerful for general import into the Word/PowerPoint UI paradigms |
| 13:21 | <hsivonen> | virtuelv: so you'd need to have a profile |
| 13:21 | <hsivonen> | and profiles suck, too |
| 13:22 | <hsivonen> | there are lots and lots of abstraction level mismatches both ways between HTML+CSS and the de facto office suite feature set |
| 13:29 | <Dashiva> | virtuelv: Better get started on ISO5 |
| 13:30 | <virtuelv> | well, I no longer regard (and again, highly personal opinion) ISO as a standards body |
| 13:31 | <Dashiva> | When even China manages to get the no vote right, it's quite embarrassing for Norway |
| 13:59 | <hsivonen> | the whole idea of countries voting makes no sense when the Finnish subsidiaries of IBM, MS and Google are taken as Finnish companies |
| 14:46 | <zcorpan> | would it be possible to hardcode the html tag names as "not the mathml namespace" within <math> and every other tag would be "unknown-in-mathml-namespace"? |
| 14:47 | <zcorpan> | also, i think making /> self-close is needed for copy-pasting svg into text/html |
| 14:48 | <zcorpan> | because, e.g., a <circle> can have contents |
| 14:49 | <zcorpan> | i'd also like to look at actual pages that have <math> or <svg> with non-mathml or non-svg tags in them |
| 14:49 | <zcorpan> | otherwise i'm not convinced that scoping doesn't work :P |
| 14:49 | <hsivonen> | zcorpan: putting random junk in the MathML namespace without a <math> parent seems like a bad idea on the face of it |
| 14:50 | <zcorpan> | hsivonen: i meant withing <math> |
| 14:50 | <hsivonen> | I'm not convinced that scoping doesn't work, either |
| 14:50 | <zcorpan> | i.e. <math><foo><table> -> <m:math><m:foo><html:table> |
| 14:50 | <zcorpan> | Hixie: ^ |
| 14:53 | <Dashiva> | hsivonen: That algorithm you posted has a break in the middle of the outer loop. Doesn't seem right. |
| 14:55 | <hsivonen> | Dashiva: oops. |
| 15:27 | <hsivonen> | http://www.robweir.com/blog/2008/04/new-paths-in-standardization.html |
| 15:35 | <hsivonen> | http://sqweek.dnsdojo.org/language-evolution.jpg |
| 15:37 | <Lachy> | I thought ISO 29500 was Microsoft's OOXML. Is VML included as part of that? |
| 15:38 | <hsivonen> | Lachy: yes |
| 15:39 | <hsivonen> | it includes a replacement for MathML as well |
| 15:39 | <Lachy> | ok, wow. I never thought IE would be first to support a standard. Oh, well, congratulations to the IE team :-) |
| 15:40 | <Lachy> | ah, excellent. Reinventing things is always a good idea |
| 15:40 | <Lachy> | </sarcasm> |
| 15:45 | hsivonen | wonders if Det Norske Veritas or somesuch sells OOXML conformance certificates |
| 16:47 | gsnedders | finds bizarre python behaviour |
| 16:49 | <gsnedders> | was IE not the first browser to have any CSS support, FWIW? |
| 16:49 | <gsnedders> | (re what Lachy was saying) |
| 16:49 | <gsnedders> | http://pastebin.ca/967662 |
| 16:55 | <webben_> | gsnedders: Which one was first perhaps depends on how narrowly you define "CSS", but according to this Arena was first: http://virtuelvis.com/archives/2005/01/css-history |
| 16:56 | <webben_> | http://www.w3.org/Arena/0.98 |
| 17:18 | <hasather> | gsnedders: The \fffd's seems to be the source of that bug |
| 17:19 | <hasather> | ... or maybe not |
| 17:34 | <annevk> | hmm, changing the way unknown elements are parsed seems dangerous |
| 17:45 | <gsnedders> | hasather: on the fact of it, they are |
| 17:45 | <gsnedders> | hasather: but playing around with it makes me think otherwise |
| 17:45 | <gsnedders> | hasather: it's odd™ |
| 18:11 | <toruvinn> | hi there. |
| 18:29 | gsnedders | makes his one and only post regarding video for this month |
| 18:31 | <hsivonen> | hmm. action in the Forms TF |
| 19:48 | <Hixie> | wow |
| 19:48 | <Hixie> | well |
| 19:48 | <Hixie> | that's pretty clear cut |
| 19:50 | <andersca> | hey Hixie |
| 19:50 | <Hixie> | 200000 files with presentational mathml; 5000 with content mathml; 3000 with both. (out of about 7 billion files of all types) |
| 19:50 | <Hixie> | crap, late for meeting. |
| 19:50 | <Hixie> | bbl. |
| 20:07 | <toruvinn> | phew, i'm back. i've got a question for you guys about a correct browser's behaviour with canvas. let's assume a canvas with width/height set to 50, and canvas.style.width/height set to 100px. obviously the image gets resized. now what happens with pixel-manipulating methods, should they use .style coordinates or (more likely) canvas' .width and .height? also, if they use direct (as in non-CSS) properties, how should onmousemove/click (and |
| 20:08 | <Philip`> | toruvinn: Your message got cut off after "onmousemove/click (and" |
| 20:09 | <toruvinn> | how should onmousemove/click (and other events) behave? |
| 20:09 | <toruvinn> | (Philip`, thanks) |
| 20:09 | <toruvinn> | should the events be launched on a 100x100px square, or the 50x50px (canvas' dimensions) square? |
| 20:10 | <Philip`> | Things like get/putImageData always use the canvas coordinate space, i.e. just depend on the <canvas width height> size and not be affected by CSS at all |
| 20:11 | <Philip`> | (Insert grammar as needed) |
| 20:11 | <toruvinn> | cause currently i have a little problem in opera, when the canvas' style/non-style dimensions differ, the events are fired for whatever the browser displays (that is, streched image), but it can't really get the pixel colour under the cursor (it's outside canvas) |
| 20:11 | <toruvinn> | so, is it up to the user agent or up to the website's JS code to recalculate the coordinates? |
| 20:12 | <toruvinn> | i tried to find the relevant information in HTML5 specs, unfortunately with no luck. |
| 20:12 | <Philip`> | I would expect mouse events to just depend on the CSS-rendered rectangle size, and not have any special cases for resized canvases (or imgs or etc), though I don't know if/where this is all defined |
| 20:13 | <virtuelv> | toruvinn: I would say that the behaviour you're describing sounds like the correct way |
| 20:13 | <Philip`> | although from what I've seen in practice, mouse coordinates are completely messed up and it's impossible to write a single piece of code that will work in two or more browsers :-/ |
| 20:13 | <toruvinn> | Philip`, currently opera's beta fires the events for the CSS-rectangle (quite correct imo), but trying to work on the image around the event's .offsetX/.offsetY is confusing. |
| 20:14 | <virtuelv> | toruvinn: you need to use a correction factor if your css dimensions differ from canvas dimensions |
| 20:14 | <toruvinn> | i'd really have to recalculate (scale) the offsets to get the proper pixel coordinates |
| 20:14 | <virtuelv> | or just never ever set a different css size |
| 20:14 | <toruvinn> | virtuelv, ah, so it's up to the webmaster's JS. |
| 20:14 | <toruvinn> | ok, i guess opera behaves correctly in that case. ;-) |
| 20:15 | <toruvinn> | thanks a lot! |
| 20:15 | <virtuelv> | toruvinn: I really can't say I can find another _sane_ way to do it |
| 20:15 | <virtuelv> | if there needs to be rounding going on, you can just as well do it in JS, as the browser trying to do it |
| 20:17 | <toruvinn> | mhm. thanks! |
| 21:35 | <Dashiva> | liorean's <a> parsing smells like SGML |
| 21:51 | <hasather_> | Dashiva: yea, but he got it wrong |
| 21:57 | <jgraham_> | <uncharitable>2004 called, it wants it's HTML-as-SGML discussion back</> |
| 22:03 | <Dashiva> | Them's fighting words |
| 22:04 | <Dashiva> | The video thing also looks like it's trying to resurface... |
| 22:13 | <mitsuhiko> | the xhtml as html compatibility plan was the most ridiculous idea ever |
| 22:13 | <mitsuhiko> | now browser vendors cannot implement either of it :) |
| 22:14 | hsivonen | has made way too many email edit errors today. time to go to bed |
| 22:30 | <gsnedders> | Dashiva: forgive me for replying |
| 22:31 | <Dashiva> | I'm in no position to pass judgement, I just comment :) |
| 22:31 | <gsnedders> | I try not to reply :P |
