| 00:03 | <Hixie> | hober: isn't there equivalent text outside the example? |
| 00:05 | <dbaron> | danbeam, hober, it's explicitly undefined in the spec, and one of the architectural issues with transitions |
| 00:06 | <dbaron> | "Since this specification does not define when computed values change, and thus what changes to computed values are considered simultaneous, authors should be aware that changing any of the transition properties a small amount of time after making a change that might transition can result in behavior that varies between implementations, since the changes might be considered simultaneous in some implementations but not others." |
| 00:07 | <dbaron> | er, wait, the case you mentioned is defined |
| 00:07 | <dbaron> | never mind |
| 00:07 | <hober> | Hixie: /me looks |
| 00:08 | <dbaron> | however, you might not get a transition if the element was never actually displayed with the previous value of transform |
| 00:10 | <hober> | Hixie: if there is I can't find it |
| 00:10 | <Hixie> | k let me look one sec |
| 00:11 | <Hixie> | i wonder if i broke this when i did the arraybuffer change |
| 00:12 | <Hixie> | no, looks like it was always broken |
| 00:12 | <Hixie> | ok |
| 00:13 | <Hixie> | can you send mail to whatwg mentioning that it doesn't say anywhere that getImageData() is to return the backing store directly? |
| 00:13 | <hober> | Hixie: will do |
| 00:13 | <hober> | Hixie: thanks |
| 00:13 | <Hixie> | thanks |
| 00:17 | <ojan> | TabAtkins: you there? i have moar flexbox questions. |
| 00:23 | <Philip`> | Hixie: Doesn't the "must result in no visible changes to the rendering" thing imply that getImageData must return the backing store, since anything else would be lossy? |
| 00:34 | <danbeam> | dbaron: where is the case I mentioned defined? |
| 00:38 | <dbaron> | danbeam, "When the computed value of an animatable property changes, implementations must decide what transitions to start based on the values of the ‘transition-property’, ‘transition-duration’, ‘transition-timing-function’, and ‘transition-delay’ properties at the time the animatable property would first have its new computed value. " |
| 00:40 | <Hixie> | Philip`: good point |
| 00:40 | <Hixie> | Philip`: maybe i should add a note to that effect? |
| 00:48 | <hober> | Hixie: sounds good to me |
| 00:51 | <Hixie> | ok i'll turn the paragraph you (hober) quoted earlier into a note after the paragraph Philip` quoted |
| 00:51 | <Hixie> | sound good? |
| 00:52 | <Hixie> | aw man, bug 13328 is gonna be a pain |
| 00:52 | <Hixie> | i guess i should write a script to do the conversion automatically |
| 00:56 | <Hixie> | ok i checked in the change above |
| 01:06 | <danbeam> | hober, dbaron: thank you for your help |
| 05:24 | <Hixie> | i like anne's newscaster style for the whatwg weeklies |
| 05:24 | <Hixie> | just needs some good music to go with it. |
| 06:07 | <nessy> | Hixie: would it be appropriate to send an email to whatwg about what is happening around webvtt at W3C? |
| 06:07 | <Hixie> | i'll do it once something actually happens |
| 06:08 | <nessy> | did you see http://www.w3.org/community/texttracks/ ? |
| 06:08 | <nessy> | the group actually got created today, so I thought it appropriate to explain why we're doing it |
| 06:08 | <nessy> | happy for you to do it if you prefer |
| 06:08 | <Hixie> | group creation doesn't count as "something actually happening" :-) |
| 06:09 | <nessy> | fair enough :-) |
| 06:09 | <Hixie> | annevk5: http://www.youtube.com/watch?v=1Bg5BPnmj68 |
| 06:09 | <Hixie> | enjoy :-) |
| 06:13 | <nessy> | lol |
| 08:06 | <annevk5> | haha |
| 09:12 | <annevk5> | nessy, maybe announce the WebVTT CG and whether it plans to fork or not on the WHATWG list? |
| 09:12 | <annevk5> | nessy, somewhat unclear what the relation to the WHATWG is from your blog post |
| 09:39 | <annevk> | oh missed the earlier conversation somehow |
| 10:12 | <hsivonen> | annevk: do you have any guestimate when you'll get to the XHR2 text/html charset feedback? |
| 10:18 | <annevk> | hsivonen, I wanted to address it by using the parser hooks Hixie gave |
| 10:18 | <annevk> | hsivonen, Hixie will be creating* |
| 10:19 | <annevk> | hsivonen, for the responseText issue, we could wait with decoding until the first 1024 bytes are received for text/html encoding I suppose |
| 10:20 | <annevk> | hsivonen, and if chunked-text gets standardized just force UTF-8 I guess |
| 10:20 | <annevk> | (there's no relation to Document there so no reason to make things difficult) |
| 10:26 | <hsivonen> | annevk: Works for me. Let's hope there isn't much text/html responseText comet usage in the wild... |
| 10:27 | <hsivonen> | annevk: so the "text" mode would require running <meta> prescan although the HTML parser wouldn't otherwise be involved? |
| 10:27 | <hsivonen> | hmm. smaug and sicking aren't here now. :-( |
| 10:27 | <annevk> | I don't want to make "text" magic |
| 10:28 | <annevk> | responseText should work the same for empty string responseType and "text" |
| 10:28 | <hsivonen> | annevk: ok |
| 10:28 | <hsivonen> | smaug wanted "text" and chunked text to work the same |
| 10:29 | <hsivonen> | but we can't have all these properties |
| 10:30 | <annevk> | don't really see why chunked text would do special things for e.g. XML |
| 10:31 | <annevk> | but then I'm not sure we want chunked text in the first place |
| 11:20 | <zcorpan> | annevk: in xhr2, you should say in the note around "network error" that it includes "CORS check failed" |
| 11:21 | <zcorpan> | annevk: i had to read the CORS spec to figure out what should happen in xhr2 when the cors check fails |
| 11:23 | <annevk> | I don't follow |
| 11:23 | <annevk> | For XHR you need to know "cross-origin request status" |
| 11:23 | <annevk> | which is defined by CORS |
| 11:23 | <annevk> | so yes, you need to read CORS |
| 11:26 | <zcorpan> | if i'm an author, and want to use somebody else's CORS-enabled resource, i want to only read the xhr spec |
| 11:26 | <zcorpan> | and know what behavior will kick in when the CORS check fails |
| 11:27 | <zcorpan> | right now it appears to be undefined (but it's not, the Note is just wrong) |
| 11:28 | <zcorpan> | (uh, maybe i was reading an unrelated Note) |
| 11:29 | <zcorpan> | network error |
| 11:29 | <zcorpan> | A DNS error, TLS negotation failure, or other type of network error occured. This does not include HTTP responses that indicate some type of error, such as HTTP status code 410. |
| 11:29 | <zcorpan> | says the cors spec |
| 11:29 | <zcorpan> | but network error includes failed CORS check |
| 11:31 | <hsivonen> | I'm all for mentioning CORS there, but will doing so deadlock both specs on the REC track? |
| 11:32 | <hsivonen> | (I'd probable prefer specs that tell the whole truth over specs that advance on the REC track) |
| 11:33 | <zcorpan> | the note was in the cors spec |
| 11:35 | <jgraham> | hsivonen: The solution is to not care about the rec track |
| 11:47 | <annevk> | I'm even more confused now |
| 11:47 | <hsivonen> | maybe I'm confused |
| 11:48 | <annevk> | zcorpan, so in XMLHttpRequest you are reading the "same-origin request event rules" and expect they apply to CORS scenarios? |
| 11:49 | <zcorpan> | annevk: no i realized that was bogus :) |
| 11:49 | <zcorpan> | annevk: what i did originally was follow the link in the xhr cross-origin steps and came to cors's definition of "network error" |
| 11:50 | <zcorpan> | annevk: which doesn't say that it includes CORS check fail |
| 11:50 | <zcorpan> | but it does |
| 11:51 | <annevk> | so http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#cross-origin-request-status (not XMLHttpRequest) should be clearer about "network error"? |
| 11:51 | <zcorpan> | yeah |
| 11:51 | <annevk> | I would agree that should probably include "the resource cannot be shared" |
| 11:57 | <annevk> | zcorpan, done |
| 12:00 | <zcorpan> | annevk: thanks! |
| 14:23 | <benjoffe> | I missed the whole discussion on why '$' was chosen as the subject modifier |
| 14:24 | <benjoffe> | but "E:has-descendent(selector)" seems much more fitting to the existing pattern |
| 14:25 | <benjoffe> | is there a strong reason to choose $ over that pattern? |
| 14:27 | <zcorpan> | specificity? |
| 14:27 | <zcorpan> | shorter? |
| 14:28 | <benjoffe> | could be E:has(selector) |
| 14:30 | <zcorpan> | still different specificity |
| 14:30 | <jgraham> | The people who invented selectors hate readability? |
| 14:30 | zcorpan | wasn't part of the discussion though |
| 14:31 | <zcorpan> | though there's :matches and :not already |
| 14:31 | <zcorpan> | so yeah |
| 14:32 | <annevk> | no idea |
| 14:34 | <bga_> | annevk, question about opera. Do you plan to add text selection on page w/o mouse. i really <3 shift + arrows but want cursor to select text as in design mode too. |
| 14:42 | <annevk> | bga_, I think so, but I'm not sure what the ETA is |
| 14:46 | <benjoffe> | sounds like an extension could be made for it, might require ugly off screen textarea hacks though |
| 14:54 | <annevk> | added appendChild("trololol") and friends to the DOM |
| 14:55 | <annevk> | taking bets on whose first to implement and ship |
| 14:56 | <Ms2ger> | Not us |
| 14:57 | <Ms2ger> | We don't support overloading yet :( |
| 14:57 | <bga_> | annevk appendChild('<pre>1</pre>')? |
| 14:58 | <annevk> | bga_, it's not HTML |
| 14:58 | <bga_> | textnode? |
| 14:58 | <annevk> | yes |
| 14:58 | <Ms2ger> | Right |
| 14:59 | <Ms2ger> | Also, hi annevk |
| 14:59 | <annevk> | wb Ms2ger |
| 14:59 | <bga_> | annevk i can make monkey patch which do that :) |
| 14:59 | <Ms2ger> | Do it :) |
| 15:00 | <bga_> | sec |
| 15:01 | <annevk> | stuff like http://annevankesteren.nl/2005/05/greasemonkey does not count ;) |
| 15:02 | <Ms2ger> | annevk, isn't that how Opera passed Acid3? ;) |
| 15:07 | <bga_> | annevk http://pastie.org/2617153 |
| 15:08 | <annevk> | stuff like that works? |
| 15:08 | <annevk> | crazy |
| 15:08 | <Ms2ger> | Sure does |
| 15:10 | <Ms2ger> | # [15:27] <annevk5> where is ms2ger? |
| 15:10 | <Ms2ger> | Anything in particular you needed me for? |
| 15:12 | <annevk> | prolly to take a look at the exception stuff |
| 15:13 | <Ms2ger> | Mm |
| 15:13 | <Ms2ger> | My opinion on anything related to exceptions is "meh", fwiw |
| 15:14 | <annevk> | fair enough |
| 15:14 | <annevk> | wonder why smaug hasn't landed your EventException patch |
| 15:14 | <annevk> | kind of lame |
| 15:17 | <annevk> | anyone know when heycam is going to be back? |
| 15:17 | <annevk> | I would rather not define how to handle some arbitrary JS Object myself |
| 15:19 | <Ms2ger> | <heycam> just dropping in to say I'm on vacation for the next 4 weeks, see you all later |
| 15:19 | <Ms2ger> | From the ninth |
| 15:22 | <Ms2ger> | Hixie, any reason you didn't close http://www.w3.org/Bugs/Public/show_bug.cgi?id=13030? |
| 15:22 | <annevk> | thanks |
| 16:24 | <Hixie> | Ms2ger: just a mistake, i think |
| 16:24 | <Hixie> | annevk: if there are hooks you need sooner rather than later, please mark the relevant bugs critical |
| 16:26 | <annevk> | thanks, guess I'll do that to help hsivonen out |
| 18:06 | <boblet> | does anyone have a good reason why <u> is more appropriate than <mark> for indicating spelling errors, other than default rendering? |
| 18:15 | <Hixie> | boblet: it's the same reason why <dfn> is more appropriate than <cite> for indicating definitions |
| 18:17 | <boblet> | Hixie: I’d guess you mean more specific, except that <cite> doesn’t seem appropriate for definitions :) for me the semantics seem a little closer in that case |
| 18:17 | <boblet> | (that case = spell checker) |
| 18:17 | <Hixie> | boblet: <mark> is as appropriate for spelling mistakes as <cite> is for definitions :-) |
| 18:18 | <Hixie> | boblet: <mark>'s definition is "a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context" |
| 18:18 | <Hixie> | boblet: unless you're specifically talking about the spelling mistakes, that definition doesn't have anything to do with spelling |
| 18:20 | <boblet> | Hixie: for me highlighting and annotating were closer, but I can see <u> is more appropriate |
| 18:21 | <boblet> | Hixie: while you’re around, CJK etc languages with non-western name order sometimes indicate the family name via capitalisation, underline or aside. would you say <u> would be appropriate for e.g. hcard, restyled to text-transform:uppercase? |
| 18:21 | <Hixie> | sure |
| 18:22 | <boblet> | that usage isn’t so popular, eg. Wikipedia has an aside, but I’ve seen it used for Japanese names before |
| 18:22 | <Hixie> | an aside? |
| 18:23 | <boblet> | well, a note above the article’s introduction stating the name order and which word is the family name |
| 18:23 | <Hixie> | ah |
| 18:23 | <Hixie> | weird |
| 18:24 | <boblet> | eg: http://en.wikipedia.org/wiki/Mao starts with “This is a Chinese name; the family name is Mao” |
| 18:25 | <boblet> | well, capitalising etc could be perceived as western imperialism as western names don’t get that treatment :) |
| 18:34 | <Hixie> | boblet: oh, well, no markup is necessary in the case of the wikipedia convention |
| 18:34 | <Hixie> | boblet: certainly i wouldn't expect <u> to be used. <aside> maybe. |
| 18:35 | <boblet> | true, true. but good to know <u> works for cases when the family name is directly indicated (as hcard needs wrapper elements anyhow) |
| 18:38 | <Hixie> | boblet: yeah, <u> is perfect for that. <u> is for when you are annotating something, but not explicitly saying what it is. |
| 18:39 | <Hixie> | boblet: i.e. where the annotation's meaning is implied by context |
| 18:40 | <boblet> | Hixie: yup :) just checking I understand before publishing. playing it safe after getting a little burned on <footer> in <blockquote> :D |
| 18:41 | <boblet> | didn’t know about proper name marks either — interesting |
| 18:42 | <TabAtkins> | 521042 |
| 18:42 | <Hixie> | boblet: heh, understood! |
| 18:43 | <TabAtkins> | Dammit, focus'd the wrong window. |
| 18:43 | <Hixie> | TabAtkins: 521043? |
| 18:43 | <TabAtkins> | Well, that OTP expires in a few seconds. |
| 18:43 | <Hixie> | 892729! |
| 18:43 | <boblet> | 90210!! |
| 18:43 | <Hixie> | -43.4i+2! |
| 18:43 | <TabAtkins> | [1,2,3,4]! |
| 18:44 | <boblet> | hey TabAtkins, why is text-decoration specced as “Value: <text-decoration-line> || <text-decoration-color> || <text-decoration-style>”, not line, style then color (which would be more in keeping with border)? |
| 18:45 | <TabAtkins> | I have no idea. The ordering is insignificant, though. |
| 18:46 | <boblet> | TabAtkins: I (now) know that, but I suspect ppl who don’t understand || won’t realise that. I couldn’t find || in the CSS syntax doc btw |
| 18:46 | <boblet> | might email www-style about it… |
| 18:46 | <TabAtkins> | Syntax is wildly out of date (I have a note on my whiteboard to volunteer to put a big "THIS IS OBSOLETE STOP LOOKING AT IT" marker on several specs). |
| 18:46 | <Ms2ger> | TabAtkins, is the ordering still insignificant wrt CSSOM serialization? |
| 18:46 | <TabAtkins> | It's explained in 2.1, though. |
| 18:46 | <Ms2ger> | TabAtkins, please do :) |
| 18:47 | <boblet> | everything in TR? [ducks] |
| 18:47 | <TabAtkins> | Ms2ger: Nobody follows CSSOM serialization so far. |
| 18:47 | <TabAtkins> | Or at least, that part of it. |
| 18:47 | <Ms2ger> | boblet, yes, please |
| 18:48 | <boblet> | Ms2ger: kk |
| 18:48 | <Ms2ger> | TabAtkins, nobody follows any spec, as a first approximation ;) |
| 18:49 | <TabAtkins> | Ms2ger: "Doesn't exactly match every single detail" and "completely ignores" are pretty different. |
| 18:49 | <Hixie> | TabAtkins: the ordering isn't insignificant, it impacts serialisation |
| 18:50 | <TabAtkins> | Hixie: See above conversation. |
| 18:50 | <Ms2ger> | Hixie, beat you to it :) |
| 18:50 | <Hixie> | i was still reading :-) |
| 18:50 | <Hixie> | TabAtkins: they certainly won't implement it while the order is treated as insignificant in the specs :-) |
| 18:50 | <Hixie> | at least not interoperably :-) |
| 18:50 | <TabAtkins> | ^_^ |
| 18:55 | <Hixie> | any opinions on http://www.w3.org/Bugs/Public/show_bug.cgi?id=13174#c2 ? |
| 18:55 | <Hixie> | it seems a bit dubious to me, but i can't quite work out what i'd suggest instead |
| 18:56 | <TabAtkins> | The example in #7 seems reasonable. |
| 18:59 | <Hixie> | annevk: you around? |
| 18:59 | <Hixie> | #7 is the real-world instance of #2 |
| 18:59 | <TabAtkins> | Yes, I know. |
| 18:59 | <Hixie> | my concern is that people will start putting all kinds of shit in <th>, like <hx>, <article>s, etc |
| 19:00 | <Hixie> | but i agree that that specific example seems like the least bad way of marking up that semantic |
| 19:00 | <Hixie> | i guess i could explicitly only allow non-sectioning, non-heading content or something |
| 19:00 | <TabAtkins> | Just put an example in, explaining what not to do? Specifically, the spec could probably do with some text about Aryeh's example. |
| 19:00 | <Hixie> | yeah, maybe being explicit in an example is enough? |
| 19:05 | <Hixie> | annevk: see webapps |
| 19:27 | <danbeam> | Hixie: can you help me interpret HTML5 7.6.5, second ordered list, 4.1-2 (http://dev.w3.org/html5/spec/dnd.html#drag-and-drop-processing-model)? |
| 19:28 | <danbeam> | (or anybody else that's well versed with this spec.) |
| 19:28 | <Ms2ger> | danbeam, give me a link to the whatwg version and I can try :) |
| 19:29 | <danbeam> | Ms2ger: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#drag-and-drop-processing-model |
| 19:30 | <danbeam> | Ms2ger: (second ordered list, 4.1-2) |
| 19:31 | <danbeam> | Ms2ger: my question is simply, "If there will be a 'drop' event, should it *have* to complete before a 'dragend'?" |
| 19:33 | <Ms2ger> | I think so, yes |
| 19:33 | <danbeam> | Ms2ger: it sure seems to be implied that it's a "yes" |
| 19:43 | <Hixie> | danbeam: what do you mean by "complete"? |
| 19:44 | <danbeam> | Hixie: should a "drop" event fire and be synchronously executed and completed before a "dragend" event is fired? |
| 19:45 | <TabAtkins> | annevk: I can't find the CSSValue interface defined anywhere in CSSOM. Am I missing something? |
| 19:47 | <Ms2ger> | TabAtkins, I assume he means the CSS*Value interfaces at http://dev.w3.org/csswg/cssom/Overview.html#the-csspropertyvalue-interface and later |
| 19:48 | <TabAtkins> | Ms2ger: Well, 6.6.4 and 6.6.5 have things specifically returning a CSSValue. |
| 19:49 | <Ms2ger> | So they do |
| 19:50 | <Hixie> | danbeam: unless one of the event handlers dispatches its own event, event dispatch is always entirely synchronous within a task |
| 19:50 | <TabAtkins> | annevk: Maybe you mean CSSComponentValue there, and for the other types like CSSStringComponentValue to inherit from CSSComponentValue? |
| 19:50 | <Ms2ger> | I assume it'll be a superclass, then |
| 19:51 | <TabAtkins> | Yeah, for now I'm just going to ape what CSSOM is doing. |
| 19:57 | <danbeam> | Hixie: yes, that was my understanding as well, but check your PM |
| 19:58 | <Hixie> | yeah i looked at that |
| 19:58 | <danbeam> | Hixie: ok |
| 20:00 | <danbeam> | Ms2ger, Hixie: thank you for your help |
| 20:00 | <Ms2ger> | Np |
| 20:09 | annevk | wonders what sicking is on about |
| 20:10 | <annevk> | TabAtkins, what is the context you are talking about? |
| 20:10 | <annevk> | TabAtkins, nothing inherits from each other and nothing is exposed to prevent code from depending on specifics that can later be changed (if we change e.g. what value a property takes) |
| 20:11 | <annevk> | TabAtkins, basically a given property will return an object that implements several CSS value related interfaces |
| 20:11 | <annevk> | Hixie, thanks for the email, hopefully hsivonen will look into it |
| 20:16 | <TabAtkins> | annevk: Hm, okay. Well, I'm trying to define what I assume will be CSSVariableComponentValue. If it doesn't inherit from CSSComponentValue, it needs to expose a .value by itself? |
| 20:33 | <rniwa> | AryehGregor: if you're specing selection behavior, please make sure to spec selectstart event as well |
| 20:33 | <rniwa> | AryehGregor: in particular, bugs like https://bugs.webkit.org/show_bug.cgi?id=66948 are interesting to follow |
| 20:35 | <annevk> | TabAtkins, no, all properties accepting <variable> would simply implement CSSVariableComponentValue as well |
| 20:36 | <annevk> | I looked again at CSSOM today and yesterday and wondered what I would need to change, but I still think the current model is sensible |
| 20:36 | <TabAtkins> | Yes, but CSSVariableComponentValue itself has a name and a value. |
| 20:36 | <annevk> | The problem is I guess that it's a) difficult and b) not implemented yet |
| 20:37 | <annevk> | TabAtkins, ah yeah, you would have to name them variableName and variableValue |
| 20:37 | <TabAtkins> | Ah, kk. |
| 20:37 | <annevk> | sweet |
| 20:37 | <annevk> | gonna get some cocktails now :) |
| 20:37 | <TabAtkins> | I'll ping you for review on this stuff later. |
| 20:38 | <annevk> | great |
| 20:38 | <sicking> | annevk: what do you mean? |
| 20:38 | <TabAtkins> | Drink a cocktail for me! |
| 20:39 | sicking | heads out to lunch |
| 20:50 | <Ms2ger> | http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0297.html |
| 20:50 | <Ms2ger> | For your enjoyment |
| 20:51 | <TabAtkins> | That's so last week, Ms2ger. |
| 20:51 | <Ms2ger> | No comment |
| 20:51 | <TabAtkins> | Btw, the correct answer is "Make the change you want to the template without asking anyone, because everyone's crazy." |
| 20:52 | <TabAtkins> | My mistake there. |
| 20:52 | <Ms2ger> | "everyone's crazy." |
| 20:52 | <Ms2ger> | I could have told you that :) |
| 20:54 | <TabAtkins> | If I define a getter in idl, do I just define the meaning of it in prose? |
| 20:54 | <Ms2ger> | Yes |
| 20:54 | <TabAtkins> | Also: I don't understand what makes "creator" different from "setter". |
| 20:55 | <Ms2ger> | creator is when the property doesn't exist yet, setter is when it does |
| 20:55 | <Hixie> | what Ms2ger said |
| 20:55 | <TabAtkins> | I suspected as much, but wasn't sure. |
| 20:55 | <TabAtkins> | ok. |
| 21:06 | <sicking> | back |
| 22:02 | <rniwa> | Hixie: sorry about the delay in responding to your stuff |
| 22:02 | <rniwa> | Hixie: I think I still have to ask you about some cache state |
| 22:03 | <rniwa> | Hixie: I'm intending to work on it next week. I've been ramped up by a bunch of regression fixes in WebKit in the last couple of weeks :( |
| 22:03 | <rniwa> | Hixie: but I just replied to your bug about drag&drop |
| 22:03 | rniwa | needs to respond to clipboard API spec as well |
| 22:04 | <rniwa> | man... participating in standardization process requires such a time commitment |
| 22:05 | <dsfsf> | uh huh |
| 22:19 | <sicking> | Hixie: ping |
| 22:59 | <Hixie> | rniwa: don't worry about delay, i often have month-long lag with dealing with stuff :-/ |
| 22:59 | <Hixie> | sicking: pong |
| 23:01 | <sicking> | Hixie: drats, i forget what i was going to ask :( |
| 23:01 | <sicking> | Hixie: well, since i have your attention, do you read bugzilla.m.o bugmail? |
| 23:01 | <Hixie> | sicking: i read some of it. i have filters. i don't follow as many active people as i used to so i don't get as much as i'd like these days. |
| 23:02 | <Hixie> | sicking: if i'm cc'ed and the comment says "HTML5" or "WHATWG" or other similar keywords I tend to see it |
| 23:02 | <sicking> | Hixie: specifically https://bugzilla.mozilla.org/show_bug.cgi?id=641148 |
| 23:02 | <Hixie> | didn't see that one, no |
| 23:02 | <Hixie> | looking now |
| 23:04 | <Hixie> | henri's comment seems accurate |
| 23:05 | <sicking> | Hixie: well.. i don't have an opinion on the sg: rating |
| 23:05 | <sicking> | Hixie: but it does seem like having consistent <script> parsing no matter where the markup appears has lots of advantages |
| 23:05 | <Hixie> | it has advantages and disadvantages, sure |
| 23:06 | <sicking> | Hixie: though at this point I suspect the person to convince is Henri |
| 23:06 | <sicking> | ? |
| 23:06 | <sicking> | Hixie: what are the disadvantages? |
| 23:06 | <Hixie> | well, convincing henri is both sufficient and necessary, so probably, yes :-) |
| 23:06 | <sicking> | Hixie: also, *everything* has disadvantages, the question is how big they are |
| 23:06 | <Hixie> | disadvantages include the issues he listed |
| 23:06 | <Hixie> | like being able to take svg and put it in html and just have it work |
| 23:07 | <Hixie> | a new disadvantage here is that it would involve breaking compat with shipped browsers |
| 23:08 | <sicking> | Hixie: the SVG WG says that copy-paste of SVG should work just fine |
| 23:08 | <Hixie> | the SVG WG says a lot of things |
| 23:08 | <Hixie> | doesn't mean they're true :-) |
| 23:08 | <sicking> | sure, but in this case i'd their experience over yours to be honest |
| 23:09 | <Hixie> | there's plenty of scripts that say > instead of > and similar, deep inside a for loop |
| 23:09 | <sicking> | in SVG? |
| 23:09 | <Hixie> | in scripts in SVG or other XML |
| 23:10 | <sicking> | other XML doesn't matter here |
| 23:10 | <Hixie> | i'm sure authors would just put up with it if we made it so that such scripts would need changing |
| 23:10 | <Hixie> | but it _would_ mean that you can't just copy and paste |
| 23:10 | <sicking> | likewise they'd put up with it if they have to adjust the script when copy-pasting |
| 23:10 | <Hixie> | also, we'd have to change the CDATA thing |
| 23:10 | <Hixie> | anyway, as you said earlier, i'm not really the one to convince |
| 23:10 | <sicking> | ok |
| 23:10 | <sicking> | i'll chat with henri |
| 23:11 | <Hixie> | chat with abarth, too |
| 23:11 | <sicking> | yup |
| 23:11 | <sicking> | thanks |
| 23:12 | <Hixie> | seriously though, "the SVGWG said so" is no more convincing than "Hixie said so". if we're going to base this on what is compatible, then we'd need real data. |
| 23:12 | <Hixie> | not heresay or anecdotal evidence. |
| 23:12 | <Hixie> | (another difference would be comment parsing inside scripts, i wonder how many svg files have commented-out content in <script> blocks) |
| 23:13 | <sicking> | well.. i suspect that the SVG WG has a lot more experience looking at the markup that various tools output |
| 23:13 | <sicking> | and so far most of the SVG which is generated, is generated using tools i bet |
| 23:14 | <shepazu> | sicking: it certainly is |
| 23:14 | <shepazu> | usually inkscape, sometimes Illustrator |
| 23:15 | <shepazu> | I'm not convinced that just dropping SVG into HTML would necessarily work |
| 23:15 | <sicking> | especially when scripts are involved |
| 23:15 | <sicking> | since the DOM will be very different |
| 23:15 | <shepazu> | not even all SVG content generated by Inkscape or Illustrator works in browsers |
| 23:15 | <sicking> | the <svg> element won't be the documentElement for example |
| 23:16 | <shepazu> | yes, a lot of SVG with script assumes that SVG is the root |
| 23:16 | <shepazu> | right |
| 23:16 | <shepazu> | not sure who said it would just work... |
| 23:16 | <Hixie> | sicking: we've tried quite hard to make it so the DOM differences are minimised |
| 23:16 | <shepazu> | but I'm on the SVG WG, and I'm not at all confident about that |
| 23:17 | <Hixie> | sicking: btw i commented on the bug. i agree that it's a potential security risk, and i think henri underplays the risk. hopefully my comment will help. |
| 23:18 | <sicking> | Hixie: cool, thanks |
| 23:18 | <Hixie> | shepazu: when we first started working on adding svg parsing in html, the svg wg's most ardent request was that it be possible to take raw SVG files and paste them into text/html without modifications and have the parser handle it exactly as if it was SVG in XML |
| 23:19 | <Hixie> | shepazu: a number of reasons were given, such as making sure that errors made in editing SVG in HTML wouldn't be accepted and thus "corrupt" the pristine SVG ecosystem, and making it possible for output from SVG tools could be dropped straight into HTML files without work. |
| 23:19 | <shepazu> | Hixie: yes, I think that was a reasonable request |
| 23:19 | <shepazu> | I don't know for a fact that that was accomplished, either in the HTML5 spec or in implementations |
| 23:20 | <Hixie> | at least the second part of that is only reasonable if one is confident that SVG content dropped into HTML would in fact just work |
| 23:20 | <shepazu> | there's also author education around how to write the script correctly such that it doesn't break… but that's not really an authoring tool issue, unfortunately… not many good tools for scripting SVG |
| 23:39 | <dbaron> | TabAtkins, how stable is the to <side-or-corner> stuff for gradients in css3-images ? |
| 23:40 | <dbaron> | TabAtkins, (I've been asked to review a patch implementing it.) |
| 23:40 | <TabAtkins> | It's stable now. I'm not changing anything now. I plan in the near future to write an email explaining that I'm not changing anything about radial either. |