| 00:01 | <TabAtkins> | jdaggett: Mind if I clean up the Fonts event stuff to hook into DOM Core terminology and whatnot? No significant changes from your perspective, just synchronization and tightening of some definitions. |
| 00:02 | <Hixie> | TabAtkins: (plus scoped fonts for <style scoped>, though i dunno how to even do that given the cascade) |
| 00:03 | <TabAtkins> | I don't think impls accept that <style scoped> scopes resource loads like that. |
| 00:03 | <Hixie> | TabAtkins: right now the spec doesn't have a conceptual list at all, as far as i can tell, it's all implied that hte fonts are reset on page load, etc |
| 00:04 | <TabAtkins> | Hixie: Yeah, there's no concept of it yet. Just saying that it's an easy thing to define. |
| 00:05 | <Hixie> | agreed |
| 00:07 | <Hixie> | (<style scoped> has to have some solution for font scoping, otherwise two different scoped blocks defining the same font differently would conflict) |
| 00:07 | <TabAtkins> | Yes. I think that problem is what impls plan to stick themselves with. |
| 00:08 | <Hixie> | it's not a problem for impls, it's a problem for syndicators using scopes styles. |
| 00:08 | <TabAtkins> | Sure. But it's impls that decide whether they'll do anything about it. ^_^ |
| 00:09 | <Hixie> | it would be sad if we didn't find a solution, but yeah |
| 00:09 | <Hixie> | wouldn't be the first time we screwed authors, certainly :-) |
| 00:09 | <TabAtkins> | Same thing with all the name-defining at-rules, like @counter-style. |
| 00:11 | <Hixie> | yeah |
| 00:11 | <Hixie> | we really should find a solution |
| 00:11 | <Hixie> | maybe it's as "simple" as automatically munging names to be prefixed with the block's name or something? |
| 00:15 | <Hixie> | in other news, rewriting the entire canvas section to compatible with workers is about as mind-numbing as rewriting a library to be thread-safe |
| 00:19 | <Hixie> | oh.... bummer. |
| 00:20 | <TabAtkins> | "The block's name"? There is no such thing. |
| 00:20 | <Hixie> | addHitRegion is going to be exciting |
| 00:20 | <Hixie> | TabAtkins: an anonymous one |
| 00:20 | <Hixie> | TabAtkins: not one the author can see |
| 00:20 | <TabAtkins> | Oh, and then rewrite all references inside the stylesheet as well? |
| 00:20 | <TabAtkins> | Contextually? |
| 00:20 | <Hixie> | (s/anonymous/internal/) |
| 00:20 | <Hixie> | something like that |
| 00:20 | <TabAtkins> | That sounds unfun. |
| 00:21 | <Hixie> | yeah |
| 00:21 | <Hixie> | hrm |
| 00:21 | <Hixie> | really no idea how to do addHitRegion() |
| 00:22 | <Hixie> | oh i guess it's no so bad |
| 00:27 | <jamesr> | Hixie, i don't think you could call addHitRegion() from the worker anyway, since that's about interactivity with the DOM and you can't really manipulate interactive things from a worker |
| 00:27 | <Hixie> | you can, it just ends up pushing the data to the main thread |
| 00:27 | <Hixie> | the only thing you can't do is use the 'control' thing |
| 00:29 | <Hixie> | TabAtkins: can you think of any way in which changing the directionality would affect the metrics measured in a canvas TextMetrics object? |
| 00:29 | <Hixie> | bounding box, positions of baselines, advance width... |
| 00:29 | <Hixie> | i guess if a ( and a ) have different dimensions |
| 00:29 | <Hixie> | hmm |
| 00:30 | <zewt> | kerning differences? |
| 00:31 | <Hixie> | hm yeah I guess "+-" could kern differently than "-+" |
| 00:31 | <zewt> | oh, i was thinking horizontal vs. vertical, but i guess that applies to rtl too |
| 00:32 | <Hixie> | oh i'm not talking about the writing direction, just the directionality |
| 00:32 | <zewt> | yeah |
| 00:32 | <Hixie> | canvas doesn't do vertical text yet |
| 00:53 | <jdaggett> | TabAtkins: can you send me a patch with whatever changes you want to make? |
| 00:54 | <jdaggett> | TabAtkins: then I'll move it back into the src |
| 08:00 | <zcorpan> | hsivonen: https://twitter.com/builtwith/status/268951926085910528 https://twitter.com/W3Techs/status/268835927500148737 we'll see if they publish correct reports next |
| 08:15 | <hsivonen> | zcorpan: thanks |
| 08:17 | <zcorpan> | hsivonen: do you have any ideas for how to approach http://bugzilla.validator.nu/show_bug.cgi?id=945#c7 ? |
| 08:30 | <hsivonen> | zcorpan: the datatype back end can report which character was the problem. I don’t recall how well (if at all) the front end handles that data |
| 08:30 | <hsivonen> | zcorpan: but I expect it to not handle line breaks in the attribute value very well |
| 08:35 | <zcorpan> | hsivonen: ok |
| 08:45 | <hsivonen> | zcorpan: yeah, the front end doesn’t handle the error index given by the back end: http://html5.validator.nu/?doc=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%3C!DOCTYPE+html%3E%3Ctitle%3E%3C%2Ftitle%3E%3Cinput+type%3Drange+step%3D0.k5%3E |
| 09:18 | <MikeSmith> | zcorpan: yeah I think this is a general limitation for all the attribute-microsyntax checking |
| 09:18 | <zcorpan> | yeah :-( |
| 09:18 | <MikeSmith> | maybe can try to figure out some clever way to get past it |
| 09:19 | <zcorpan> | can the front end be fixed to use the position that the back end reports? |
| 09:20 | <MikeSmith> | possibly |
| 09:21 | <MikeSmith> | though even if we do that it's not clear to me how it's going to handle line breaks in attribute values |
| 09:22 | <MikeSmith> | anyway I'll mess around with it a bit |
| 09:51 | <MikeSmith> | zcorpan: one thing I guess we could have it do it is, emit the entire current command expression it was parsing when it found the error |
| 09:52 | <MikeSmith> | just one command along with all its arguments |
| 09:53 | <MikeSmith> | do you think would that be useful enough that I should bother to try adding it? |
| 09:54 | <zcorpan> | MikeSmith: giving a small context around the error seems good enough to be able to locate the error |
| 09:55 | <MikeSmith> | OK |
| 09:56 | <zcorpan> | MikeSmith: the message doesn't trim the attribute value, but the source extract does. that seems like a bug |
| 09:57 | <zcorpan> | MikeSmith: maybe the message should omit the value completely if it's longer than some value |
| 09:57 | <MikeSmith> | yeah |
| 09:58 | <MikeSmith> | that would not be too hard to change |
| 09:58 | <MikeSmith> | so I wonder how long is too long |
| 10:01 | <MikeSmith> | 300 characters? |
| 10:01 | <MikeSmith> | 200? |
| 10:08 | <MikeSmith> | zcorpan: btw the attribute value doesn't get trimmed in the source extract either, does it? |
| 10:09 | <zcorpan> | my test case in the bug seems to get trimmed in the source extract |
| 10:10 | <MikeSmith> | strange |
| 10:10 | <MikeSmith> | it doesn't for me |
| 10:10 | <MikeSmith> | can you make a screen shot? |
| 10:11 | <MikeSmith> | the extract I'm seeing has the whole element emitted and highlighted in red |
| 10:11 | Ms2ger | mumbles something about CSS specs |
| 10:11 | <zcorpan> | um. now it doesn't |
| 10:13 | <MikeSmith> | zcorpan: ok |
| 10:14 | <zcorpan> | MikeSmith: if i use <img src="aaaaaaaa b"> where there are many "a"s, i get trimmed source extract. |
| 10:14 | <zcorpan> | d>↩<body>↩<img src="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa…aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa b">↩</bod |
| 10:14 | <MikeSmith> | oh |
| 10:14 | <zcorpan> | i thought i saw that for d="" previously as well |
| 10:15 | <MikeSmith> | I'll take a look at that part of the message code |
| 10:16 | <MikeSmith> | for the riduculously-long case I can have it truncate the value or omit it completely |
| 10:16 | <MikeSmith> | in both places |
| 10:17 | <zcorpan> | i think i'd prefer omit in the message and truncate in the source extract |
| 10:17 | <MikeSmith> | OK |
| 10:18 | <MikeSmith> | that makes sense |
| 10:18 | <zcorpan> | as for too long, let's go with 200, since that's about as long as the truncated highlighted source extract is |
| 10:19 | <MikeSmith> | yeah that's what I was thinking too |
| 10:19 | <MikeSmith> | 300 is too long |
| 10:35 | <kmbarnhart> | Can someone answer a question I have about the WebVTT specification |
| 10:35 | <kmbarnhart> | Sepecifically, a number of times the spec states "one or more characters other than" and say line feed and ampersand |
| 10:37 | <kmbarnhart> | It seems to me that that means line feed and ampersand are not allowed at all |
| 10:38 | <kmbarnhart> | Which would mean that in the cue text cannot have newline or an & without & |
| 10:39 | <zcorpan> | kmbarnhart: right, line feed and ampersand are not allowed at all for that particular part of the syntax it's discussing, because they have special meaning and are allowed in other parts of the syntax |
| 10:39 | <kmbarnhart> | ok thanks |
| 10:40 | <zcorpan> | kmbarnhart: e.g. with the cue data "foo & bar", there is text "foo ", entity "&" and text " bar" |
| 10:40 | <zcorpan> | kmbarnhart: ampersand is not allowed in the text parts |
| 10:40 | <zcorpan> | does that make sense? |
| 10:41 | <kmbarnhart> | yes. I was a bit unclear because ok, however the newline issues is contrary to the non-normative example and is allowed by the parser |
| 10:42 | <zcorpan> | can you explain what the newilne issues are? |
| 10:42 | <zcorpan> | newline, even |
| 10:42 | <kmbarnhart> | The part I'm concerned with is here http://dev.w3.org/html5/webvtt/#webvtt-cue-text-span |
| 10:43 | <kmbarnhart> | The example here: http://dev.w3.org/html5/webvtt/#cues-with-multiple-lines |
| 10:43 | <zcorpan> | see http://dev.w3.org/html5/webvtt/#webvtt-cue-text |
| 10:44 | <zcorpan> | each line is a cue text span |
| 10:45 | <kmbarnhart> | ok ic |
| 10:45 | <kmbarnhart> | I missed that, thank you |
| 10:45 | <zcorpan> | np |
| 10:46 | <zcorpan> | (each line in the example in the spec, i mean. a line can have several webvtt components, too.) |
| 14:45 | <annevk> | Oh Mozilla killed XML Events. Well Opera, when will you? |
| 14:48 | <smaug____> | Does Opera have XML Events? |
| 14:48 | <smaug____> | for what? |
| 14:48 | <smaug____> | XML Events require special kinds of event listeners |
| 14:49 | <smaug____> | xforms elements or such |
| 14:49 | <smaug____> | Don't remember how that all worked in X+V |
| 14:52 | <darobin> | I didn't know anyone supported XML Events in the first place |
| 14:53 | <jgraham> | If you supported XML events you would keep quiet about it too |
| 14:53 | <darobin> | yeah you would, nasty buggers to use they were |
| 15:01 | <smaug____> | XML Events was the first larger contribution I made to Gecko (2004, I think) . And now I removed it :) |
| 15:28 | <annevk> | Pretty sure Opera has it for SVG |
| 15:29 | <annevk> | Opera also still has xml:id :-( |
| 16:51 | <dglazkov> | good morning, Whatwg! |
| 17:41 | <tantek> | good morning dglazkov! |
| 18:18 | <TabAtkins> | jdaggett: Looks like Ms2ger handled the rewrite for me. His suggested patch looks good on its face. |
| 18:19 | <Ms2ger> | TabAtkins, not to me, half of it needs to be filled in still |
| 18:20 | <TabAtkins> | Ms2ger: The part you've filled in looks fine with me skimming it, though. |
| 19:30 | <Hixie> | should scrollPathIntoView() in a worker do anything? |
| 19:31 | <Hixie> | (i could, in theory, have it remember what it was told to scroll to, and when you call commit(), have it tell teh main thread to actually do that scroll) |
| 19:33 | <TabAtkins> | Interesting. |
| 19:33 | <TabAtkins> | That sounds useful, actually. |
| 19:34 | <TabAtkins> | It would probably be good, as much as possible, to make the deferred canvas act like the original canvas would, just delayed by the commit(). |
| 19:35 | <Hixie> | ok |
| 19:38 | <Hixie> | so when you're doing this worker-to-main-thread thing, i push the bits out when the main thread is in a stable state (between tasks) |
| 19:38 | <Hixie> | (though i suppose i could queue a task) |
| 19:39 | <Hixie> | anyway. if, for whatever reason, the "worker" is actually script running on the same thread, should commit() switch to being synchronous? i'm thinking not, it should still queue... |
| 19:54 | <Hixie> | context.fillRect(0,0,10,10); context.drawImage(context, 20,0); -- how many rectangles? |
| 19:54 | <Hixie> | i was planning on making it one rectangle in workers and two for the case where you getContext() |
| 19:55 | <Hixie> | (because in the former case you have to commit() and the latter you don't) |
| 19:55 | <Hixie> | but i'm thinking maybe it should always be two |