| 01:12 | <zewt> | hmm. what specs (other than webgl) have entry points that take numeric arrays (int[], float[])? can't think of any |
| 01:13 | <zewt> | every search engine ever written has been useless at searching for "int[]" |
| 03:30 | <Hixie> | i wish there was a way in CSS to say 'width: fill-the-container-but-for-the-purposes-of-shrink-wrap-act-as-if-you-had-a-width-of-0' |
| 07:13 | <annevk> | we're gonna mention "Document Object Model"? hmm |
| 07:14 | <Ms2ger`> | Oh, was that the first? |
| 07:14 | <annevk> | if we do <code>Text</code> we should also do <code>DocumentType</code> I think |
| 07:14 | <annevk> | I think so |
| 07:15 | <annevk> | I carefully avoided it thus far I think |
| 07:15 | <Ms2ger`> | I didn't find concept-text :) |
| 07:15 | <annevk> | fair enough |
| 07:31 | <annevk> | hmm |
| 07:31 | <annevk> | the shift_jis algorithm advertised everywhere is quite complex, but why... |
| 07:31 | <annevk> | compare: |
| 07:31 | <annevk> | JPROW = 94 |
| 07:31 | <annevk> | def get_sjis_i2(lead, trail): |
| 07:31 | <annevk> | leadoffset = 0xC1 if lead > 0x9F else 0x81 |
| 07:31 | <annevk> | trailoffset = 0x41 if trail > 0x7F else 0x40 |
| 07:31 | <annevk> | return (lead-leadoffset) * (2 * JPROW) + trail - trailoffset |
| 07:31 | <annevk> | def get_sjis_i1(lead, trail): |
| 07:31 | <annevk> | adjust = 1 if trail < 0x9F else 0 |
| 07:31 | <annevk> | leadoffset = 0x70 if lead < 0xA0 else 0xB0 |
| 07:31 | <annevk> | trailoffset = (0x41 if trail > 0x7F else 0x40) if adjust else 0x9F |
| 07:31 | <annevk> | return ((((lead - leadoffset) * 2) - adjust) - 0x21) * JPROW + trail - trailoffset |
| 07:32 | <annevk> | gives identical results |
| 07:46 | <annevk> | not enough shift_jis people here huh? :) |
| 08:32 | <annevk> | hmm |
| 08:32 | <annevk> | Gecko... |
| 08:32 | <annevk> | <meta charset=gbk><a></a><script>var a = document.getElementsByTagName("a")[0]; a.href = "?\u20AC"; alert(a.href) </script> |
| 08:32 | <annevk> | Y U NO WORK?! |
| 08:35 | <annevk> | but given an index (which I have) and a function to convert a point in an index to a byte sequence (which is not too hard), testing encoders should be fairly straightforward |
| 08:35 | <annevk> | except in Gecko |
| 08:41 | <annevk> | hmm |
| 08:41 | <annevk> | you have to account for duplicates somehow too |
| 12:33 | <Velmont> | Hixie: I think most do. |
| 12:34 | <Velmont> | Would be really cool to have in the css though, -- not too nice if you don't have tab-complete. fill-the-container-but-for-the-purposes-of-shrink-wrap-act-as-if-you-had-a-width-of-0 -- guess it'll also be hard to remember exactly. :P |
| 12:44 | <annevk> | seems like my alternative shift_js math is correct |
| 13:28 | <annevk> | oh hey, that thing I was talking about the other day is called a fencepost error |
| 13:28 | <annevk> | http://en.wikipedia.org/wiki/Off-by-one_error |
| 16:49 | <MikeSmith> | jzaefferer or scott_gonzalez if you're around, wanted to ask how many files total are in your test suite |
| 16:50 | <jzaefferer> | MikeSmith: About 300 |
| 16:51 | <MikeSmith> | oh OK |
| 16:51 | <MikeSmith> | so that's fine |
| 16:51 | <TabAtkins> | Hixie: You can get that behavior by saying that the intrinsic width is 0, but it defaults to width:fill (defined in Writing Modes). |
| 16:52 | <MikeSmith> | jzaefferer: I put together a command-line validation client that won't require you to run the service to validate your files. But I'm waiting on hsivonen to get back to review the code before I land it |
| 16:52 | <Hixie> | TabAtkins: oh, cool |
| 16:52 | <Hixie> | TabAtkins: is that anywhere close to being implemented? |
| 16:52 | <MikeSmith> | jzaefferer: it will reduce your validation time to a few seconds |
| 16:52 | <TabAtkins> | Nobody's touched it, but it's just "what width:auto does for blocks", so implementation is trivial once someone cares about it. |
| 16:54 | <MikeSmith> | jzaefferer: minimum of 4 seconds or so to validate your 300 files, but validation time for each file will be reduced to 20ms or at most 100ms I think |
| 16:54 | <scott_gonzalez> | MikeSmith: That's great. |
| 16:55 | <MikeSmith> | will require a single jar file |
| 16:55 | <MikeSmith> | about 18MB |
| 16:56 | <MikeSmith> | which is the other thing I need to talk to hsivonen about |
| 16:57 | <MikeSmith> | we currently don't actually distribute any third-party cod |
| 16:57 | <MikeSmith> | *code |
| 16:57 | <Hixie> | TabAtkins: bummer |
| 16:58 | <MikeSmith> | scott_gonzalez: making a single jar available requires distributing 3rd-party code, so I want to make sure hsivonen is OK with that before we do it |
| 16:58 | <scott_gonzalez> | ok |
| 17:14 | <TabAtkins> | Hixie: Are you using this for a spec, or for something real? |
| 17:14 | <Hixie> | real |
| 17:14 | <Hixie> | i come across it all the time |
| 17:14 | <TabAtkins> | Ah, never mind then. |
| 17:15 | <Hixie> | whenever i have something that shrinkwraps, e.g. a dialog or something, but it has to shrinkwrap around some widgets, and yet the dialog also contains text that can wrap |
| 17:15 | <Hixie> | and i'm happy for the text to wrap at whatever width the dialog ends up at |
| 17:16 | <TabAtkins> | Ah, but the dialog instead fills the parent, because the text is long enough to force that shrink-wrapping beahvior. |
| 17:16 | <TabAtkins> | Interesting. |
| 17:35 | <Hixie> | what should happen if you click or mouseover an element that is outside a modal dialog |
| 17:35 | <Hixie> | should i just ignore the event? |
| 17:36 | <Hixie> | or should i do something more subtle, like only kill click events or something |
| 17:38 | <Hixie> | i think i'll just kill all user interaction events and prevent all focusing of elements outside the modal subtree and its ancestors |
| 17:38 | <TabAtkins> | I think that's legit. |
| 17:40 | <Hixie> | i'm going to introduce inert="" as well while i do this, so that you can have semi-modal dialogs as some people have requested |
| 17:40 | <Hixie> | and make it use the same infrastructure |
| 17:55 | <Hixie> | ok inertism (inertia? :-) ) blocks user interaction events and makes things not focusable |
| 17:55 | <Hixie> | anything else it should block while i'm at it? |
| 17:55 | <Hixie> | (bbiab) |
| 17:57 | <scott_gonzalez> | Hixie: I don't recall the cross-browser specifics, but you might need to go into detail about how find/highlighting works while an inert element is open. |
| 17:58 | <scott_gonzalez> | A quick test shows that in Chrome if an element has focus and you bring up the find interface, you can search for text on the page and then press escape to create a range around the first result of the find, which moves focus to the range. |
| 17:59 | <scott_gonzalez> | I recall doing that a lot when I was testing modal plugins a few years ago to see how well they worked. |
| 18:16 | <rafaelw_> | annevk, smaug___, sicking: re: MutationObservers attributeFilter discussion. |
| 18:16 | <sicking> | rafaelw_: yes? |
| 18:16 | <rafaelw_> | question: MutationRecord.name (when type="attribute") |
| 18:17 | <rafaelw_> | in the case of xml, is that prefix:localName |
| 18:17 | <rafaelw_> | or just localName |
| 18:17 | <rafaelw_> | ? |
| 18:18 | <sicking> | looking |
| 18:18 | <rafaelw_> | i.e. what information is reported in the MutationRecord. |
| 18:18 | <rafaelw_> | ? |
| 18:18 | <sicking> | rafaelw_: note that attributes in the xlink namespace might not have a prefix |
| 18:18 | <sicking> | so they can have .name === .localName |
| 18:21 | <sicking> | rafaelw_: currently .attributeName is set to the name per spec, not localName |
| 18:21 | <sicking> | rafaelw_: lemme look what we do in our impl |
| 18:23 | <rafaelw_> | WebKit appears to report localName right now. |
| 18:23 | <rafaelw_> | ;-( |
| 18:23 | <sicking> | yeah, we do the same in gecko |
| 18:23 | <sicking> | i prefer that behaviro |
| 18:23 | <sicking> | behavior |
| 18:24 | <rafaelw_> | reporting only localName? |
| 18:24 | <sicking> | .name is rarely useful from a correctness point of view |
| 18:24 | <sicking> | actually, especially in the case of mutation observers, when you are often observing someone else's code, it makes much more sense to ignore prefixes |
| 18:24 | <sicking> | yeah, we only report localName |
| 18:25 | <rafaelw_> | but won't it be ambiguous what happened? |
| 18:25 | <rafaelw_> | you may not know what attribute changed? |
| 18:28 | <TabAtkins> | Hixie: The word you're looking for is "inertness". |
| 18:29 | <TabAtkins> | Hixie: What happens if you start selecting non-inert text, and drag into inert text? |
| 18:30 | <TabAtkins> | Hixie: And did you handle accesskeys/etc? |
| 18:46 | <rafaelw_> | sicking: ^^. if only localName is reported, isn't that potentially ambiguous? |
| 18:54 | <smaug____> | rafaelw_: ? |
| 18:54 | <rafaelw_> | hey. trying to settle the attributeFilter question. |
| 18:55 | <rafaelw_> | the thing I was asking is what does MutationRecord.name report if type='attribute' |
| 18:55 | <rafaelw_> | name or localName. |
| 18:55 | <rafaelw_> | apparently the spec says name, but both of us implemented localName. |
| 18:55 | <smaug____> | yes |
| 18:55 | <rafaelw_> | and my question is: isn't that potentially ambiguous for XML? |
| 18:55 | <smaug____> | because localName actually makes sense ;) |
| 18:55 | <rafaelw_> | i.e. you won't know which attribute changed. |
| 18:55 | <smaug____> | how would it be more ambiguous than name ? |
| 18:56 | <rafaelw_> | if an element has foo:bar & foo2:bar and you get told that 'bar' changed. |
| 18:56 | <smaug____> | you need to check namespaceuri + localName |
| 18:57 | <rafaelw_> | i'm assuming that namespaceURI would be the same for both foo:bar and foo2:bar. |
| 18:57 | <rafaelw_> | maybe i'm missunderstanding how this all works. it looks to me like there are three things: namespaceURI, prefix and localName |
| 18:58 | <rafaelw_> | where name == prefix:localName |
| 19:00 | <rafaelw_> | smaug___: am I misunderstanding something? |
| 19:00 | <smaug____> | I don't think so |
| 19:00 | <smaug____> | :) |
| 19:00 | <smaug____> | rafaelw_: remember, namespaced attributes may not always have a prefix |
| 19:00 | <rafaelw_> | can the example i gave above occur? |
| 19:01 | <smaug____> | I would assume no, but I'm not actually sure |
| 19:02 | <smaug____> | rafaelw_: not possible http://www.w3.org/TR/REC-xml-names/#uniqAttrs |
| 19:02 | <rafaelw_> | you assume it doesn't currently, or it *can't*. |
| 19:03 | <smaug____> | foo:bar and foo2:bar where foo and foo2 are prefixes for the same namespace isn't possible |
| 19:06 | <rafaelw_> | i see. |
| 19:06 | <rafaelw_> | i get it know. |
| 19:06 | <rafaelw_> | thank you. ok, I agree. localName seems like the right thing. |
| 19:10 | <rafaelw_> | do we need a bug to change to spec to say that MutationRecord.name reports localName only? |
| 19:15 | <smaug____> | rafaelw_: I assume the spec would need to be changed in order to fix that that attributeFilter too |
| 19:15 | <smaug____> | not sure if annevk prefer separate bugs |
| 19:17 | <smaug____> | rafaelw_: btw, is the GC handling I proposed ok to you ? |
| 19:17 | <annevk> | it still seems wrong to me to standardize on local name given that most APIs around non-namespaced attributes care about qualified name |
| 19:17 | <annevk> | e.g. Attr.name, setAttribute(), getAttribute(), hasAttribute(), etc. |
| 19:20 | <rafaelw_> | smaug___: yp. GC handling is right. It's what we implemented (though we didn't have tests and it turns out we had a bug -- which is now fixed). |
| 19:28 | <Hixie> | scott_gonzalez, TabAtkins: thanks, will consider those points |
| 19:32 | <sicking> | rafaelw_: looking at attributeName + attributeNamespace should make it unambiguous |
| 19:33 | <sicking> | rafaelw_: sorry, i was unclear. We gecko only looks at localName + namespace of attributes |
| 19:33 | <sicking> | rafaelw_: what we don't look at is the name (== localName + prefix) |
| 19:33 | <sicking> | rafaelw_: looking at the name is generally more a convenience thing, since it's a single string trying to describe a tuple |
| 19:33 | <sicking> | rafaelw_: but it's more error prone since it breaks down if someone is using different prefixes than you think they are |
| 19:34 | <sicking> | rafaelw_: in other words, I think the behavior webkit and gecko has implemented is better than what the spec does since it's less error prone in all cases, and only harder to use in extremely rare edge cases |
| 19:38 | <rafaelw_> | i get it now. thanks. |
| 19:38 | <rafaelw_> | i agree. |
| 19:55 | <sicking> | rafaelw_: cool |
| 21:13 | <TabAtkins> | Hm. If you were writing a parser for CSS, for a spec, would you do it as a flat tokenization phase followed by a full tree-build phase, or a more intelligent tokenization phase that handles some elements of the syntax, followed by a somewhat light tokenization phase? |
| 21:14 | <TabAtkins> | s/light tokenization/lighter tree-building/ |
| 21:15 | <TabAtkins> | Basically I'm wondering if I should handle CSS's rule that statements/blocks can't end while there's an unmatched ([{ on the stack at the tokenizer or the tree-builder level. |
| 21:20 | <TabAtkins> | Hrm. I think I should do the flat tokenization approach, which means rewriting some things. |
| 21:33 | <Hixie> | TabAtkins: imho the quicker you move things from dealing with characters and strings to something more abstract, the better, so i'd go with a light tokeniser at the top that turns things into tokens, and then some sort of processor on top of that to get something structured |
| 21:34 | <Hixie> | TabAtkins: but that's just because i like dealing with strongly typed tokens more than with strings and characters :-) |
| 21:35 | <TabAtkins> | Hixie: I think you're right. Having to switch levels between raw characters and tokens is annoying. |
| 21:36 | <Hixie> | also don't forget you can have multiple levels, not just two |
| 21:36 | <Hixie> | like, one level to get tokens, one to wrap the tokens up into nested blocks, and then finally one to actually process the blocks |
| 21:36 | <TabAtkins> | It means the tokenizer has to do a bit more work in some cases, because I have much less contextual knowledge (I can't just say "oh, you're starting a selector. consume until you see '{' or EOF.) |
| 21:36 | <TabAtkins> | Yeah. |
| 21:36 | <Hixie> | yeah some of your tokens might be a bit special |
| 21:37 | <Hixie> | in CSS it's not so bad though because the escaping is the same everywhere and there's little ambiguity iirc |
| 21:37 | <Hixie> | e.g. an ident is an ident everywhere, whether it's a tag name or a property name or a media query type |
| 21:37 | <TabAtkins> | Yeah. |
| 21:37 | <Hixie> | (might be some exceptions but i can't think of any) |
| 21:37 | <TabAtkins> | Selectors are... weird. |
| 21:38 | <TabAtkins> | I think I need to parse ".foo" as a DELIM followed by an IDENT. :/ |
| 21:38 | <Hixie> | can't you do almost everything using only the tokens ident, punctuation ([, (, {, :, +, >, spaces, etc), strings ("...", '...'), and comments (/*...*/)? |
| 21:39 | <Hixie> | oh and numbers |
| 21:39 | <TabAtkins> | Yeah, maybe. |
| 21:39 | <Hixie> | so the tokeniser can do \unescaping |
| 21:39 | <Hixie> | i dunno i'm saying this all from memory :-) |
| 21:39 | <Hixie> | anywho |
| 21:39 | <TabAtkins> | I want to be a touch smarter to I'll directly get PERCENTAGE and DIMENSION rather than NUMBER + IDENT, but basically yeah. |
| 21:40 | <Hixie> | you need context for that iirc |
| 21:41 | <Hixie> | consider font: 1em 1em; |
| 21:41 | <Hixie> | which is equivalent to font: initial; font-size: 1em; font-family: "1em"; |
| 21:41 | <TabAtkins> | Nah, that's fine actually. font-family parses a bunch of idents. We regularized that last year. |
| 21:41 | <TabAtkins> | No special parsing rule there. |
| 21:41 | <Hixie> | really? font: 1em 1em is invalid now? |
| 21:41 | <TabAtkins> | I think it might allow numbers/dimensions too. |
| 21:42 | <TabAtkins> | The point is that font-family doesn't require anythign special until you actually parse the declaration itself. |
| 21:42 | <TabAtkins> | No special bheavior is needed at the lower levels. |
| 21:42 | <Hixie> | my point is that you have to treat "font:1em 1.0em" and "font:1em 1em" differently |
| 21:42 | <Hixie> | but i might be wrong i guess :-) |
| 21:43 | <Hixie> | should be easy to test what browsers do now that they support @font-face |
| 21:43 | <TabAtkins> | Ah, yes, it's all idents. |
| 21:43 | <TabAtkins> | font-family: 1em; is now invalid. |
| 21:46 | <Hixie> | good to know |
| 21:46 | <Hixie> | i wonder who implements that :-) |
| 21:47 | <Hixie> | webkit gets it right |
| 21:47 | <Hixie> | gecko too |
| 21:47 | <Hixie> | nice! |
| 21:49 | <TabAtkins> | Yeah, it was tracked in the CSS2.1 testsuite once we made the change, so people should have adjusted quickly. |
| 22:38 | <Hixie> | well accesskeys are proving a mite difficult |
| 22:38 | <Hixie> | i guess i could just make commands Disabled if they are inert |
| 22:41 | <TabAtkins> | That makes sense, I suppose. |
| 22:42 | <Hixie> | that would be awesome actually |
| 22:43 | <Hixie> | it would automatically disable everything in a menu that referenced commands in that section |
| 22:43 | <Hixie> | even if the menu wasn't inert |
| 23:09 | <zewt> | so, is feras planning to ignore everyone and go ahead with his broken design? welcome to the future, where web api design is still done by blunt coercion |
| 23:12 | <hober> | zewt: ? |
| 23:12 | <zewt> | oneTimeOnly |
| 23:14 | <hober> | oh, the blob url stuff? |
| 23:15 | <zewt> | yeah |
| 23:15 | <hober> | it's so broken |
| 23:15 | <hober> | it makes me sad |
| 23:15 | <Hixie> | implement it first and ship earlier |
| 23:15 | <Hixie> | that's how it works |
| 23:15 | <zewt> | basically it's the old story: microsoft implements something broken; microsoft goes "here's the api!"; everyone goes "this is broken, here's how to fix it"; microsoft puts fingers in ears and runs away |
| 23:15 | <Hixie> | welcoem to the web |
| 23:18 | <zewt> | heh, tickets like this help make sure I don't waste time filing bugs on firefox https://bugzilla.mozilla.org/show_bug.cgi?id=641509 |
| 23:19 | <zewt> | basically about fifteen thousand people going "taking the message out of onbeforeunload breaks our stuff" and several explanations of why it's harmless to show it, and it gets ignored for a year then closed without reading any of it |
| 23:30 | <Hixie> | anyone know what i should do at the aria level for inert="" and inert subtrees generated by modal dialogs? |
| 23:30 | <Hixie> | s/generated/established/ |
| 23:31 | <othermaciej> | Hixie: is "inert" close in function to "disabled"? |
| 23:31 | <Hixie> | yeah. i was thinking aria-disabled="" might work. |
| 23:31 | <Hixie> | does "Used in Roles:All elements of the base markup" mean that it can be applied to elements regardless of role? |
| 23:31 | <othermaciej> | yes |
| 23:33 | <Hixie> | ok, aria-disabled it is. |
| 23:52 | <Hixie> | what exception should i throw if you try to showModal() a dialog that's already showing? |
| 23:52 | <Hixie> | (if you show() a dialog that's already showing, i just do it. but it seems likely that showModal()ing twice is a bug.) |
| 23:56 | <dbaron> | what makes it the same? Having the same URL? (Including query and hash?) |
| 23:56 | <Hixie> | same <dialog> element |
| 23:57 | <Hixie> | (this is not showModalDialog()) |
| 23:57 | <Hixie> | (it's <dialog>.showModal()) |
| 23:57 | <dbaron> | ah |
| 23:58 | <Hixie> | i guess NotSupportedError |