| 00:07 | <Hixie> | uh oh |
| 00:07 | <Hixie> | another parser change |
| 00:08 | <Hixie> | pretty minor, but still |
| 00:08 | <Hixie> | (nulls in mathml <mo>, <mn>, etc) |
| 00:42 | <beowulf> | hi, what part of a browser handles window.innerWidth values? is it anything to do with the js engine (by that I mean, V8 or Nitro, or what have you)? |
| 00:53 | <Hixie> | no |
| 00:54 | <beowulf> | ta |
| 01:03 | <Hixie> | http://lists.w3.org/Archives/Public/www-validator/2011Jan/0057.html |
| 01:03 | <Hixie> | "ad hoc checker" o_O |
| 01:59 | <TabAtkins_> | Suppose that I wanted to define a feature such that UAs could scan the content of a page, determine what codepoints are used, and then lazily request only the necessary codepoints from a font via some variant of range requests. |
| 01:59 | <TabAtkins_> | What group would I talk to about this? |
| 01:59 | <erlehmann> | this sounds crazy. |
| 02:00 | <TabAtkins_> | Irrelevant to my question. ^_^ |
| 02:00 | <erlehmann> | let me check if it is feasible. |
| 02:01 | <gsnedders> | TabAtkins_: CSS3 Fonts defines fetching behaviour? Or not? |
| 02:01 | <TabAtkins_> | gsnedders: No. |
| 02:01 | <gsnedders> | TabAtkins_: Also, what happens if I mutate the DOM and add more codepoints? |
| 02:02 | <TabAtkins_> | gsnedders: Not my problem directly. I'm asking for a friend. Presumably, additional requests. |
| 02:02 | <gsnedders> | TabAtkins_: I guess www-style is as good a place as any… |
| 02:03 | <TabAtkins_> | We were thinking of starting with www-font, but this is barely an issue about fonts themselves. It's a protocol issue, mainly, as the important part is the codepoint-range request. |
| 02:09 | <erlehmann> | TabAtkins_, is it really a protocol issue? i remember range requests working quite well with ogg media. |
| 02:11 | <TabAtkins_> | erlehmann: Kinda? Not sure how you'd handle it without protocol changes, unless you have a format where you can predict the codepoint locations. |
| 02:11 | <erlehmann> | TabAtkins_, that is the question, if you can do that. i tried to look it up but i am dizzy. it is 3:15AM local time, i go to sleep. |
| 02:12 | <erlehmann> | s/if/whether/g |
| 02:55 | <roc> | TabAtkins: the group depends on how you want to do this |
| 02:56 | <roc> | you should ask your "friend" if they can get by with hand-subsetted fonts and unicode-range |
| 02:57 | <TabAtkins> | roc: The idea is to pursue this as a line of experimentation for Chrome, so apparently the answer is no. ^_^ |
| 02:58 | <roc> | It may be over-generous to assume that existing APIs have been fully explored |
| 02:59 | <roc> | we seem to frequently get feature requests where that is not the case |
| 03:00 | <TabAtkins> | I know that in my chatting with the dude, he explicitly talks about why subsetting is unsatisfactory. |
| 03:00 | <roc> | What is it? |
| 03:01 | <roc> | anyway, the point stands: if you have a proposal, you can figure out what group(s) it should go to, but if you only have a problem statement, it's unclear |
| 03:01 | <TabAtkins> | Because you have to subset separately for every page if you want maximum efficiency, and monitor page changes so you know if you need to rengerate yoru subsets. |
| 03:01 | <roc> | that's not what I'm saying |
| 03:01 | <TabAtkins> | I have a problem statement. |
| 03:01 | <roc> | because what I said was totally unclear |
| 03:01 | <TabAtkins> | Heh. |
| 03:02 | <roc> | How about this: split your font into a number of different fonts, each covering some range of Unicode characters |
| 03:02 | <roc> | then apply all those fonts to the page with CSS 'unicode-range' |
| 03:02 | <roc> | A browser implementation should automatically load the subset-font(s) that are needed |
| 03:03 | <TabAtkins> | Interesting. Didn't realize we should do that. |
| 03:03 | <roc> | even if an implementation currently doesn't, it could |
| 03:04 | <roc> | I can believe that approach doesn't work well; maybe there is no adequate choice for the granularity of the subset fonts |
| 03:04 | <roc> | but I hope it's been tried |
| 03:04 | <TabAtkins> | I don't know if it has. |
| 03:04 | <TabAtkins> | Bringing it up now. |
| 03:05 | <TabAtkins> | (In email, so asynchronous.) |
| 03:05 | <TabAtkins> | In unrelated news, roc, I had a question for you about http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_serve.html |
| 03:05 | <TabAtkins> | I don't understand the distinction you're drawing between the coordinate spaces there. |
| 03:07 | <roc> | if that doesn't work well, an alternative to consider would be to see if it's possible to lay out OpenType fonts cleverly and use byte-range requests to load desired subsets; again, no new API would be needed |
| 03:08 | <TabAtkins> | Yeah, that's something we wanted to broach somewhere. |
| 03:09 | <roc> | possibly you don't have to broach it anywhere |
| 03:09 | <TabAtkins> | Broach = raise in hearing of someone who knows what they're doing, so we know if it's possible. |
| 03:09 | <roc> | just start loading the font file, once you have sufficient headers, spin up a parallel load with byte-range requests for the data you want to get quicker |
| 03:11 | <roc> | TabAtkins: I think those coordinate spaces are effectively the same; I just defined them differently because they get used differently in SVG |
| 03:12 | <roc> | for example, if your element is 20px wide, then with userSpaceOnUse a width value of "1" is 1px, but with objectBoundingBox a width value of "1" would be 20px |
| 03:13 | <TabAtkins> | Hmm. |
| 03:13 | <TabAtkins> | Does that latter one actually do something useful? |
| 03:14 | <roc> | that is how objectBoundingBox coordinates work in SVG |
| 03:15 | <roc> | 0,0 is the top-left of the "object bounding box", 1,1 is the bottom right |
| 03:15 | <TabAtkins> | Oh, ok. I don't ever use that coordinate space, obviously. |
| 03:15 | <roc> | it's quite stupid, but that's how it works |
| 03:16 | <TabAtkins> | I was wanting to specify this behavior in Image Values, and I was scratching my head at it at first. |
| 03:17 | <TabAtkins> | Your definition of userSpaceOnUse is actually very useful for the eventual unification of <image> and paint servers that I'd like to do. |
| 03:57 | <Hixie> | TabAtkins: for the font thing, roc's suggestion is probably the best place to start, but if you need something with even fewer RTTs, then you could define your own units for a range request that was basically the same syntax as the css unicode-range |
| 03:58 | <Hixie> | TabAtkins: roc's suggestions, i should say |
| 05:19 | <roc> | nessy: I wasn't trying to make people with PhDs feel ashamed, far from it. But you don't write ", PhD" after your name, and people who do are usually putting on some intimidation, that's all |
| 05:20 | <nessy> | roc: I have no problem with that :-) |
| 05:20 | <nessy> | I probably just got half of a conversation last night |
| 05:21 | <nessy> | but I do get the feeling very often - not from you specifically, but more generally - that a PhD amongst engineers is being looked down on as a waste of time and lost time to do something more productive |
| 05:21 | <nessy> | and sometimes it's true, too :-) |
| 05:22 | <nessy> | but it's also life experience and it takes hard work to actually finish a thesis |
| 05:22 | <nessy> | anyway .. onto more productive things :-) |
| 05:52 | <LoneStar99> | is the right place to ask about html5 canvas? |
| 06:00 | <hober> | LoneStar99: sure |
| 08:31 | Dashiva | wonders what's going on with RDFa light inside members-only land |
| 08:59 | <jgraham> | Dashiva: I think the fact that it is going on in Members-only land should tell you all you need to know |
| 09:00 | <jgraham> | Apparently the concept of irony has been lost on these people |
| 09:48 | <zcorpan> | what's teh security problem with converting broken utf-8 to u+fffd in websockets? |
| 10:24 | <zcorpan> | foolip: <http://www.w3.org/mid/E1QWcRS-0002EY-8u⊙jwo>; |
| 10:26 | <foolip> | zcorpan, what do you think about that? |
| 10:27 | <foolip> | HTMLTimeElement also has some extra IDL properties, are those not good for anything? |
| 10:27 | <zcorpan> | dunno |
| 10:27 | <foolip> | having an element for this purpose seems a bit odd though |
| 10:27 | <zcorpan> | yeah should be a global attribute |
| 10:28 | <foolip> | RDFa's content="" or a new itemvalue="" seems more reasonable |
| 10:28 | <zcorpan> | and no reason to drop <time> imo |
| 10:28 | <foolip> | in which case <time> can be left alone |
| 10:28 | <foolip> | right |
| 10:28 | <foolip> | although I think <time> is actually fairly useless |
| 10:28 | <foolip> | since it forbids marking up many kinds of times |
| 10:29 | <foolip> | not sure when it's better than just <span>, actually... |
| 10:29 | <foolip> | Looks like I don't have a strong opinion either way :) |
| 10:30 | <zcorpan> | will you comment on the bug anyway? |
| 10:32 | <foolip> | OK |
| 10:34 | <jgraham> | ooh more longdesc drama |
| 10:34 | jgraham | gets popcorn |
| 10:44 | <matjas> | hmm, can anyone respond to http://bugzilla.validator.nu/show_bug.cgi?id=841#c1? |
| 10:45 | <matjas> | i thought i got it the other day but now i’m confused again |
| 10:48 | <zcorpan> | replied |
| 10:49 | <matjas> | thanks, zcorpan |
| 10:50 | <matjas> | zcorpan: so is my bug title incorrect? |
| 10:50 | <zcorpan> | i'm sure hsivonen understands what it means |
| 10:51 | <matjas> | I want to understand too :) |
| 10:51 | <matjas> | is `href=foo?bar=1&baz=42` allowed or not? |
| 10:51 | <zcorpan> | it is allowed, and it does not contain any ambiguous ampersands |
| 10:52 | <zcorpan> | read the definition of ambiguous ampersand carefully |
| 10:52 | <matjas> | http://www.whatwg.org/specs/web-apps/current-work/complete/syntax.html#syntax-ambiguous-ampersand |
| 10:52 | <matjas> | oh because it’s not followed by `;` |
| 10:53 | <zcorpan> | yes |
| 10:54 | <matjas> | so where in the spec does it say the unencoded & there is allowed? |
| 10:54 | <Ms2ger> | It doesn't need to, does it? |
| 10:54 | <zcorpan> | "Attribute values are a mixture of text and character references, except with the additional restriction that the text cannot contain an ambiguous ampersand." |
| 10:55 | <zcorpan> | "text" does not ban & |
| 10:55 | <zcorpan> | (but bans U+0000 for instance) |
| 10:56 | <matjas> | but <p>foo&bar</p> isn’t allowed |
| 10:56 | <matjas> | even though “Text is allowed inside elements, attribute values, and comments.” |
| 10:57 | <zcorpan> | that's allowed afaict |
| 10:57 | zcorpan | reads the parser section to see if it matches the author section |
| 10:57 | <matjas> | not according to validator.nu — is that a separate issue then? |
| 10:59 | <zcorpan> | parser section matches |
| 11:00 | <zcorpan> | it's the same issue |
| 11:00 | <matjas> | okay, so the problem is that the definition of ambiguous ampersand changed |
| 11:00 | <zcorpan> | yes |
| 11:01 | <zcorpan> | and the parser changed what is a parse error to match |
| 11:01 | <matjas> | before the change previously stuff like href="foo&bar" had an ambiguous ampersand? |
| 11:01 | <matjas> | or what |
| 11:01 | <zcorpan> | yes |
| 11:01 | <matjas> | ok |
| 11:01 | <matjas> | so the ; requirement is new |
| 11:01 | <matjas> | i think i finally get it |
| 11:01 | <zcorpan> | :) |
| 11:01 | <matjas> | thanks for your patience, zcorpan |
| 11:03 | <zcorpan> | the parser also changed behavior for ©= which v.nu also doesn't seem to have implemented |
| 11:03 | <zcorpan> | (in attributes) |
| 11:03 | <matjas> | what about it? |
| 11:04 | <matjas> | `href=©=` shouldn’t be allowed, right? |
| 11:08 | <matjas> | are all ambiguous ampersands invalid? |
| 11:13 | <zcorpan> | they are invalid but ©= is parsed differently in attribute value and text content |
| 11:13 | <zcorpan> | but it seems that was actually implemented, i didn't test properly |
| 11:27 | <Workshiva> | Looking at setting selection and whether it triggers focus |
| 11:28 | <Workshiva> | From what I see html5 doesn't specify a focus event being fired for select() nor for setSelectionRange. However, the MDC docs specify that select() also fires focus. |
| 11:28 | <Workshiva> | And it seems Chrome fires a focus event for both of them. |
| 11:37 | <Ms2ger> | File a bug, Hixie will figure it out by Christmas |
| 11:38 | <Workshiva> | I'm looking for someone to say they've already looked into that and tell me what the resolution is going to be ;) |
| 11:48 | jgraham | just got a YSOD is spotify |
| 11:48 | <jgraham> | *in |
| 12:54 | <zcorpan> | TabAtkins: the default style for <a>, <ins> and <del> interact badly with blocks as well |
| 13:15 | <Philip`> | TabAtkins: Requesting codepoints from a font is tricky because of glyph substitutions (ligatures etc) - you can't treat each codepoint individually when deciding what bytes to download, you have to know the entire set to determine which glyphs might get used |
| 13:16 | <Philip`> | (and you can't do it by downloading the whole GSUB table and letting the client figure out the glyphs to request instead of codepoints, because that table might be hundreds of KB and would defeat the point of subsetting) |
| 13:18 | <Philip`> | Also I believe you need to dynamically compute a new GSUB table for the subset (to avoid downloading the entire thing), you can't just use a range of its original bytes |
| 13:20 | <Philip`> | (The old WEFT tool didn't recompute GSUB, it just deleted some glyph data, which is much easier but results in much larger font files) |
| 13:20 | <boblet> | Philip`: isn’t Typekit linking to several partial @font-face files as a form of obfuscation or something? |
| 13:21 | <Philip`> | boblet: Don't know, but maybe |
| 13:21 | <erlehmann> | boblet, show it. |
| 13:21 | <boblet> | I thought I read something about that when it was released. No personal knowledge |
| 13:21 | <Philip`> | It's quite possible they don't care about things like ligatures or languages that rely heavily on substitutions |
| 13:24 | <boblet> | as for TabAtkins’ usecase, it would be rad to download a basic set then request other glyphs as needed for East Asian typography |
| 13:24 | <Philip`> | http://help.typekit.com/customer/portal/articles/8071-support-for-different-languages-on-typekit suggests the only languages they support are Latin alphabet ones |
| 13:24 | <boblet> | Services like Typekit could create a CMS plugin that checks for all used characters across a site then make a site-specific subset, updating when content changes. But once the site gets large this isn’t so useful (except when kanji is involved) |
| 13:25 | <boblet> | Philip`: they have at least two (freebie) Japanese fonts |
| 13:26 | <boblet> | “We split requested fonts into multiple files and recombine them using the CSS font stack” http://blog.typekit.com/2009/07/21/serving-and-protecting-fonts-on-the-web/ |
| 13:26 | <boblet> | erlehmann: ^ ;) |
| 13:27 | <Philip`> | I think Japanese is easy too - things like Arabic and Devanagari etc are hard since they rely on complex shaping |
| 13:27 | <erlehmann> | TabAtkins, isn't fontkits way the easiest? |
| 13:28 | <jgraham> | Isn't japanese even easier since it doesn't have ligatures at all? Does it even have combining characters? |
| 13:28 | <boblet> | Philip`: true. was thinking more of the initial filesize of Japanese fonts. The M+ fonts are like 350KB per weight |
| 13:28 | <boblet> | jgraham: no combining characters, but 8,000+ glyphs |
| 13:30 | <jgraham> | Oh look I am wrong http://www.quora.com/Are-there-any-ligatures-in-CJK |
| 13:33 | <boblet> | jgraham: pretty sure those are individual glyphs not ligatures. as in キ and ロ and ㌔ are three separate code points (rather than ㌔ being made from resized/repositioned キロ) |
| 13:34 | <boblet> | the Mac Japanese Input Menu flags ㌔ as “Contains JIS X0213 unique characters” |
| 13:36 | <boblet> | If you wanted to enter ㌔ you’d have to manually select it — it wouldn’t be automatically replaced as with a western ligature |
| 14:47 | <smaug____> | zewt: ping |
| 16:15 | <Ms2ger> | What's up with http://dev.w3.org/html5/2dcontext/ being out of date? |
| 16:24 | <David_Bradbury> | Ms2ger: Maybe there haven't been any changes proposed, though updating the date to reflect that might be nice. |
| 16:24 | <Ms2ger> | There have been |
| 16:25 | <David_Bradbury> | Hmm... Then I'd poke Hixie ^ |
| 16:26 | <Philip`> | Maybe any new commits would overwrite the application of issue 131's resolution, and cause unhappiness |
| 16:26 | <Philip`> | (http://dev.w3.org/cvsweb/html5/2dcontext/Overview.html) |
| 16:27 | <David_Bradbury> | So, when are we going to start seeing the new 4D Cavnas Context gaining support? :p |
| 18:59 | <volkmar> | AryehGregor: ping |
| 18:59 | <AryehGregor> | volkmar, pong. |
| 18:59 | <volkmar> | AryehGregor: i saw you were involved in a discussion about input in DOM 3 Events... do you know, by any chance why textinput is specidified and not input? |
| 19:00 | <AryehGregor> | volkmar, was I? I don't know anything about events, sorry. |
| 19:00 | <volkmar> | AryehGregor: i were :) |
| 19:00 | <AryehGregor> | Never read any specs for them or anything. |
| 19:00 | <volkmar> | oups, you were |
| 19:00 | <AryehGregor> | You were what? |
| 19:00 | <AryehGregor> | Oh. |
| 19:00 | volkmar | is tired |
| 19:01 | <AryehGregor> | Was that the one where I said something then immediately realized I misunderstood and retracted what I said? |
| 19:01 | <volkmar> | AryehGregor: it was a thread with someone asking for onvaluechanged |
| 19:02 | AryehGregor | doesn't remember |
| 19:02 | <volkmar> | anyway, i will read more of the search results... the reason might pop out |
| 19:03 | <Ms2ger> | shepazutoo, ^ |
| 19:07 | <volkmar> | ok, i filed a bug and I will see... |
| 19:07 | volkmar | wonders why 'change' i |
| 19:07 | <volkmar> | isn't specced too |
| 20:08 | <zewt> | smaug____: pong |
| 20:20 | <smaug____> | zewt: you said something about default handling not being part of dispatchEvent |
| 20:20 | <smaug____> | just FYI, it is in all the browsers |
| 20:21 | <smaug____> | zewt: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12949#c5 |
| 20:22 | <smaug____> | it is the specs which don't match reality |
| 20:22 | <smaug____> | well, DOM 3 Events nor Web DOM Core don't need to specify default handling |
| 20:24 | <zewt> | dom 3 events says that default handlers don't happen for untrusted events, and that includes all events dispatched with dispatchEvent (except for i think one exception, which I'm having trouble recalling) |
| 20:24 | <smaug____> | that is a different |
| 20:24 | <zewt> | it's not; it means that dispatchEvent will never (modulo whatever that exception was) cause default handling to occur |
| 20:24 | <smaug____> | it could be a bug that default handlers fire when untrusted event is dispatched |
| 20:25 | <smaug____> | but it does not mean that default handling is not part of event dispatch |
| 20:26 | <zewt> | but it's not part of event dispatch :) |
| 20:26 | <zewt> | it may be implemented that way by browsers, but as that has no (that I'm aware of) visible side-effects it's not really relevant |
| 20:26 | <smaug____> | But yes, DOM 3 Events is probably too strict |
| 20:27 | <zewt> | the event model is if(dispatchEvent(e)) doDefaultBehavior(), not dispatchEvent(e, doDefaultBehavior)--the default behavior is logically part of whoever's calling for a dispatch, not internal to dispatch itself |
| 20:29 | <smaug____> | in practice the event model pre-handle-event, dispatch the event to DOM, post-handle-event |
| 20:29 | <smaug____> | event model is... |
| 20:30 | <zewt> | that's internal implementation details--can you explain what effect that has on the specced behavior? |
| 20:30 | <zewt> | in other words, what's the difference |
| 20:30 | <smaug____> | See the example http://www.w3.org/Bugs/Public/show_bug.cgi?id=12949#c5 |
| 20:31 | <smaug____> | dispatching event does do the default handling |
| 20:32 | <zewt> | yeah i think that's the odd exception, which should be treated as such--it should certainly be specced, but only to define the exception, not to change the event model to suit it |
| 20:33 | <smaug____> | but that is how browsers work |
| 20:33 | <smaug____> | the default handling is part of event dispatch |
| 20:33 | <zewt> | that just doesn't matter, it's the visible behavior that matters |
| 20:33 | <smaug____> | what we should define is that in which cases default handling can be triggered using untrusted events |
| 20:34 | <zewt> | and onclick is just a weird legacy exception |
| 20:35 | <smaug____> | It would be just easier to define the reality |
| 20:35 | <smaug____> | that default handling is part of event dispatch, and in x, y, and z cases untrusted events can trigger default handling |
| 20:35 | <zewt> | the reality is that default handling is not part of event dispatch, from the perspective of visible behavior |
| 20:35 | <smaug____> | that is not trie |
| 20:35 | <smaug____> | true |
| 20:36 | <zewt> | yes it is |
| 20:36 | <smaug____> | my example is an example where it is not |
| 20:36 | <zewt> | like i said (two or three times :) that's the odd exception, behavior that doesn't match how the event model works for everything else |
| 20:37 | <smaug____> | what "for everything else" |
| 20:37 | <smaug____> | where does the event model work differently |
| 20:37 | <smaug____> | I'd like to see an example |
| 20:38 | <zewt> | huh? you've given the *only* case I'm aware of where default behavior ends up being part of dispatch |
| 20:39 | <zewt> | and I'm certainly not arguing against speccing that behavior, but it should be treated as exceptional compatibility behavior, not as an argument that the entire event model should be based on that |
| 20:39 | <smaug____> | I'd like to see an example where the default handling is not part of the event dispatch. (it is possible that untrusted events don't trigger default handling) |
| 20:41 | <zewt> | every dispatchEvent() call in javascript; the default behavior is whatever you do if it returns true |
| 20:41 | <smaug____> | I'm not talking about script libraries |
| 20:41 | <smaug____> | but browser implementations |
| 20:41 | <zewt> | scripts are intrinsic to the event model. |
| 20:42 | <smaug____> | link handling works the same way as changing checked state. you dispatch event and the default handling for <a> triggers the navigation |
| 20:42 | <smaug____> | etc |
| 20:43 | <mpilgrim> | there's really no compilation shortcuts after you've changed 500 IDL files |
| 20:44 | <smaug____> | form submission has the default handling during event dispatch |
| 20:44 | <zewt> | not in my experience |
| 20:44 | <zewt> | var e = document.createEvent("HTMLEvents"); e.initEvent("submit", true, true); form.dispatchEvent(e); |
| 20:44 | <zewt> | if(!e.stopped) form.submit(); |
| 20:45 | <zewt> | ^ i've had to write code like that because it's not |
| 20:46 | <smaug____> | what is e.stopped? |
| 20:46 | <zewt> | (pardoning the ugly prototype.js-ism) |
| 20:46 | <zewt> | if(form.dispatchEvent(e)) form.submit(); |
| 20:52 | <smaug____> | dispatching submit event submits the form at least in Fx and Opera |
| 20:52 | <smaug____> | again, the difference in default handling can be that some browsers don't allow untrusted events to dispatch the event |
| 20:52 | <smaug____> | er |
| 20:53 | <smaug____> | again, the difference in default handling can be that some browsers don't allow untrusted events to do the default handling |
| 20:53 | <zewt> | it's the same thing (as far as visible behavior is concerned) |
| 20:54 | <zewt> | when it's a browser-dispatched event there's no difference whether default behavior is implemented inside dispatchEvent or not |
| 20:54 | <smaug____> | yeah |
| 20:54 | <smaug____> | it is the default handling of untrusted events |
| 20:54 | <smaug____> | which needs to be defined |
| 20:55 | <smaug____> | so click() can just dispatch click event and we need to define in which case untrusted events can trigger d.efault handling |
| 20:55 | <smaug____> | and the problem is solved :) |
| 20:56 | <zewt> | rather, these exceptional behaviors should be called something else, and defined as the rare exceptions they are |
| 20:57 | <zewt> | not by changing the whole event model to revolve around the one (maybe two) exceptions |
| 20:57 | <smaug____> | huh. I don't understand why we couldn't define the reality. |
| 20:57 | <smaug____> | that way click() would have strange special powers |
| 20:58 | <zewt> | huh? you can submit a click event with dispatchEvent |
| 20:58 | <smaug____> | per spec click() does more than just dispatch click event |
| 20:59 | <smaug____> | but that is not the reality |
| 20:59 | <zewt> | i think it's perfectly fine for click() to be able to do something you can't do otherwise (that's what DOM APIs do), but I don't think that matters here |
| 20:59 | <smaug____> | hmm, sounds like this discussion is not leading to anywhere :) |
| 20:59 | <zewt> | anyway, we're going in circles, and I'm not the one you need to convince anyway :) |
| 21:00 | <smaug____> | I will just reject all the insane changes to event handling in an implementation :) |
| 21:00 | <zewt> | i don't think it changes implementation behavior--so long as the weird exceptions are specced, which again (at least in DOM Core) they aren't yet |
| 21:01 | <zewt> | happen to know when Anne's due back? |
| 21:01 | <smaug____> | don't remember |
| 21:02 | <Ms2ger> | Today |
| 21:03 | <zewt> | i don't envy him his backlog, heh |
| 21:27 | <AryehGregor> | Can someone with an MDN wiki account change the spec reference here to point to CSSOM View instead of an outdated HTML5 link? https://developer.mozilla.org/en/DOM/element.scrollIntoView http://dev.w3.org/csswg/cssom-view/#dom-element-scrollintoview |
| 21:49 | <AryehGregor> | Wow, manual tests are staggeringly boring. |
| 21:49 | <AryehGregor> | Even if you can run a couple a second by just repeatedly hitting the same key, and cache the results. |
| 21:50 | <smaug____> | AryehGregor: just a second, I'll change or ask someone to change |
| 21:50 | <smaug____> | the link |
| 21:51 | <AryehGregor> | I need a small mechanical device that will press a key repeatedly for me so I can do something else in the meantime. |
| 21:51 | <AryehGregor> | smaug____, thanks. |
| 21:59 | <smaug____> | AryehGregor: updated |
| 21:59 | <AryehGregor> | smaug____, thanks. |
| 22:36 | <AryehGregor> | It's annoying when I get close to the end of a day and have finished all the major work I have and don't want to start on a new thing because I wouldn't make any progress before I stopped for the day. |
| 22:59 | <Hixie> | idea for a new css selector (based on some stuff i've talked about before): |
| 23:00 | <Hixie> | a new set of attribute selectors where the first character of the attribute is punctuation, e.g.: |
| 23:00 | <Hixie> | input[.value=foo], or video[.readyState=2] |
| 23:01 | <Hixie> | it works just like regular attribute selectors, except the value comes from the IDL attribute with the given name |
| 23:01 | <Hixie> | and to specify which IDL attributes this works with, we have a new annotation on the attributes in the IDL |
| 23:01 | <Hixie> | e.g. [ExposeToCSS] readonly attribute DOMString value; |
| 23:01 | <smaug____> | [ExposeToCSS] would work with only some types, right? |
| 23:02 | <Hixie> | yeah |
| 23:02 | <Hixie> | probably just DOMString, long, maybe boolean if we define it as presence vs absence |
| 23:03 | <Hixie> | we could also have a combinator that works via attributes that return elements |
| 23:03 | <smaug____> | and the use case is? |
| 23:03 | <Hixie> | e.g. foo /bar/ baz, where "bar" is an attribute, so e.g. img /usemap/ map selects the map of the img |
| 23:03 | <Hixie> | many use cases, e.g. selecting input elements based on their current vlaue |
| 23:04 | <Hixie> | value |
| 23:04 | <Hixie> | if we had this, we could replace :checked with [.checked], and wouldn't need to introduce new ones each time we have something else to select on |
| 23:04 | <Dashiva> | I like the sound of that |
| 23:04 | <Hixie> | e.g. instead of video:paused we can have video[.paused] |
| 23:04 | <smaug____> | yeah, sounds good |
| 23:05 | <Hixie> | the combinator is useful for e.g. selecting the control for a label, e.g. label:active /control/ input { border: thick; } |
| 23:05 | <hober> | hmm |
| 23:05 | <smaug____> | but might be tricky to implement |
| 23:05 | <Hixie> | yeah definitely tricky to implement! |
| 23:05 | <hober> | could be worth posting to www-style |
| 23:06 | <roc> | it's going to be a nightmare to implement |
| 23:06 | <Hixie> | ((fwiw, i've suggested both [.foo] and /foo/ before, the new insight here is using an IDL annotation to opt-in attributes to make this work) |
| 23:06 | <roc> | depending on which attributes you apply it to |
| 23:06 | <smaug____> | actually, I'd assume it would be very hard to make it work *fast* |
| 23:07 | <Hixie> | well like roc says, it depends a lot on what we expose |
| 23:07 | <roc> | the code for "compute me the value of this function" is often orders of magnitude easier than "signal me whenever the computed value of this function would change" |
| 23:07 | <Hixie> | indeed |
| 23:11 | <Hixie> | is there any reason other than "history" for using NodeList vs HTMLCollection? |
| 23:12 | <Hixie> | i guess nodelist can't be accessed by name |
| 23:12 | <Hixie> | uh oh, domcore has stuff that html currently has and they're getting out of sync |
| 23:13 | <Hixie> | i hope the domcore stuff is just a straight copy so it can be updated easily once i get around to nuking the stuff in html |
| 23:18 | <AryehGregor> | Is there any reason to have generic syntax like video[.paused] if it will only work for an extremely small segment of attributes anyway? |
| 23:18 | <AryehGregor> | It only makes sense if it's defined to work for a pretty broad class of attributes. |
| 23:18 | <Hixie> | why would it be "extremely small"? |
| 23:19 | <AryehGregor> | Because CSS selectors are very performance-sensitive, and it would be hard to make most IDL attributes work here. |
| 23:20 | <AryehGregor> | Implementations do stuff like intern strings so they don't have to do strcmp() when evaluating CSS selectors. Something like checking JS attributes would presumably be hard if you include lots of them. |
| 23:20 | <AryehGregor> | It might make sense even with only a small set of attributes, though. |
| 23:20 | <Hixie> | why is it ok with content attributes but not IDL attributes? |
| 23:20 | <AryehGregor> | Because then JS and CSS knowledge would be more transferrable. |
| 23:21 | <AryehGregor> | Because content attributes have a static value and are all updated through the same codepaths, IDL attributes can return something different every time you get them and they're updated through tons of different codepaths. |
| 23:21 | <AryehGregor> | Or they might not even have a value stored in any specific place at all. |
| 23:21 | <AryehGregor> | They might secretly trigger code that's specific to that particular attribute. |
| 23:21 | <AryehGregor> | Like, I dunno, querying some video-playing framework to determine if a video is paused or not, which might involve a whole bunch of function calls. |
| 23:22 | <Hixie> | well it depends on the IDL attribute |
| 23:22 | <Hixie> | most IDL attributes just reflect the content attributes, so it seems they'd be equivalent |
| 23:22 | <Hixie> | HTMLMediaElement.paused doesn't update dynamically, it's just a settabel boolean |
| 23:22 | <Hixie> | settable |
| 23:22 | <AryehGregor> | If browsers are okay with keeping two copies of everything, yeah. Maybe they already do that, in fact. |
| 23:23 | <Hixie> | you wouldn't need to keep two copies of everything, only of the attributes that you've found the css references |
| 23:23 | <Hixie> | and actually you wouldn't need to keep two copies in most cases, if they're the same |
| 23:23 | <AryehGregor> | Not for regular DOMString, no, but the common case for other types is they're not the same. |
| 23:24 | <AryehGregor> | Like all non-DOMString types. |
| 23:24 | <AryehGregor> | Many URLs aren't absolute, either. |
| 23:24 | <AryehGregor> | Enums are probably going to be exactly the same less often than not. |
| 23:24 | <AryehGregor> | But it would be useful to be able to query the actual enum state, so you don't have to worry about case variations and defaults and so on. |
| 23:25 | <Hixie> | <a href=""> already has to be checked against the history, I don't see why img[.src] (say) would be any worse, perf wise |
| 23:25 | <AryehGregor> | In fact, CSS 2.1 has some wording about attribute default values for exactly this reason. |
| 23:25 | <Philip`> | For IDL attributes that reflect content attributes, I assume you could just use the content attribute CSS selectors - the only interesting cases for the new selector are the non-reflective ones |
| 23:25 | <Hixie> | Philip`: the idl attributes tend to do some processing that might be interesting |
| 23:25 | <AryehGregor> | Philip`, not if the attribute reflects interestingly, like enumerated attributes. |
| 23:26 | <AryehGregor> | Or numbers, if you're worried you might have weirdly-formatted numbers. |
| 23:26 | <AryehGregor> | Not booleans or regular DOMStrings, no. |
| 23:43 | <AryehGregor> | Hixie, I accidentally sent a mail to whatwg a little while ago from the wrong address. Can you approve it? |
| 23:44 | <AryehGregor> | (if you don't answer within a few minutes, I'll just resend it, but someone I CC'd already responded on-list, so it would be confusing) |
| 23:44 | <Hixie> | yeah one sec |
| 23:49 | <AryehGregor> | Hixie, have you approved it yet? I have to leave in a few seconds and want to make sure the post is out before I do. |
| 23:50 | <Hixie> | sorry, couple of things bumped it down my stack |
| 23:50 | <Hixie> | getting to it now |
| 23:50 | <Hixie> | moderator says there's no pending requests |
| 23:50 | <Hixie> | looks like i have invalid addresses set to bounce permanently |
| 23:50 | <Hixie> | i think i set that because of the high volume of spam |
| 23:50 | <AryehGregor> | Okay, I'll resend it. |
| 23:52 | <AryehGregor> | Gmail could really use smarter list handling. |
| 23:53 | <AryehGregor> | Like: 1) Allowing you to easily reply to multiple posts in a thread in one e-mail (would be good for some private conversations too). 2) Flagging posts that were made off-list so you don't accidentally reply on-list (hi TabAtkins!). 3) Warning you if you try sending from the wrong address. |
| 23:54 | <Hixie> | why do you think i use pine for this stuff :-) |
| 23:54 | <Hixie> | my mail routes through gmail but i use pine as my frontend |
| 23:54 | <AryehGregor> | Did you ever give Gmail's interface a real try, or were you used to pine already and didn't bother? |
| 23:55 | <Hixie> | i use gmail for all my work mail |
| 23:55 | <AryehGregor> | My e-mail UI experience went from AOL to Gmail and that's it, I never tried anything else. |
| 23:55 | <Hixie> | where work = google internal, not, you know, my actual work... |
| 23:55 | <AryehGregor> | Gmail works well enough for me, but it would be nice if I could easily script it. |