| 00:59 | <_bga> | http://js1k.com/2012-love/demo/1243 |
| 01:00 | <_bga> | http://js1k.com/2012-love/demo/1243 |
| 01:19 | <scott_gonzalez> | Hixie: .innerHTML in IE clears the innerHTML of all descendants. Do you agree that this is a bug? |
| 01:19 | <scott_gonzalez> | http://jsfiddle.net/Hej6h/6/ |
| 01:20 | <scott_gonzalez> | Hixie: .innerHTML in IE clears the innerHTML of all descendants. Do you agree that this is a bug? |
| 01:20 | <scott_gonzalez> | http://jsfiddle.net/Hej6h/6/ |
| 01:26 | <smaug____> | it does what? |
| 01:26 | <smaug____> | it does what? |
| 01:27 | <Hixie> | scott_gonzalez: sounds like a bug, yes |
| 01:27 | <Hixie> | scott_gonzalez: sounds like a bug, yes |
| 01:27 | <scott_gonzalez> | smaug____: If you have <p><a>x</a></p> |
| 01:27 | <scott_gonzalez> | And you have a reference to the anchor element. |
| 01:27 | <scott_gonzalez> | Then you do p.innerHTML = ""; |
| 01:27 | <scott_gonzalez> | a.innerHTML will get cleared as well. |
| 01:28 | <scott_gonzalez> | smaug____: If you have <p><a>x</a></p> |
| 01:28 | <scott_gonzalez> | And you have a reference to the anchor element. |
| 01:28 | <scott_gonzalez> | Then you do p.innerHTML = ""; |
| 01:28 | <scott_gonzalez> | a.innerHTML will get cleared as well. |
| 01:28 | <scott_gonzalez> | So your reference is pretty much useless at that point. |
| 01:28 | <Hixie> | what happens to the text node's data if you still have the text node around? |
| 01:28 | <scott_gonzalez> | I haven't tried that. Let me check. |
| 01:28 | <Hixie> | what happens to the text node's data if you still have the text node around? |
| 01:28 | <scott_gonzalez> | I haven't tried that. Let me check. |
| 01:28 | <Hixie> | and what if the <a> element contains another element? |
| 01:29 | <Hixie> | and what if the <a> element contains another element? |
| 01:30 | <scott_gonzalez> | That seems to get cleared out too. |
| 01:31 | <scott_gonzalez> | That seems to get cleared out too. |
| 01:32 | <scott_gonzalez> | Same results when a contains another element. |
| 01:32 | <Hixie> | so it empties every text node and every element's child list? |
| 01:32 | <Hixie> | how weird |
| 01:32 | <scott_gonzalez> | Same results when a contains another element. |
| 01:32 | <Hixie> | so it empties every text node and every element's child list? |
| 01:32 | <Hixie> | how weird |
| 01:33 | <smaug____> | not very weird |
| 01:34 | <smaug____> | not very weird |
| 01:34 | <smaug____> | I could imagine it can help releasing memory in certain cases |
| 01:35 | <smaug____> | I could imagine it can help releasing memory in certain cases |
| 01:35 | <Hixie> | seems like it would waste a lot of cycles |
| 01:36 | <Hixie> | seems like it would waste a lot of cycles |
| 01:36 | <Hixie> | given that the memory will likely be released anyway at GC |
| 01:36 | <Hixie> | given that the memory will likely be released anyway at GC |
| 01:36 | <scott_gonzalez> | Right, it would only help if there are references to the nodes. And GC can't kick in for those until the references are removed anyway. |
| 01:37 | <scott_gonzalez> | Right, it would only help if there are references to the nodes. And GC can't kick in for those until the references are removed anyway. |
| 01:37 | <scott_gonzalez> | Although right now GC is kicking in too early if there are references. |
| 01:37 | <scott_gonzalez> | Since the nodes are staying, but they're losing all of their content. |
| 01:37 | <scott_gonzalez> | Although right now GC is kicking in too early if there are references. |
| 01:37 | <scott_gonzalez> | Since the nodes are staying, but they're losing all of their content. |
| 01:43 | <scott_gonzalez> | I'll report this to Microsoft and see what they say. |
| 01:43 | <scott_gonzalez> | I'll report this to Microsoft and see what they say. |
| 08:01 | zcorpan | discovers http://www.w3.org/TR/CSS21/aural.html#Emacspeak |
| 08:02 | zcorpan | discovers http://www.w3.org/TR/CSS21/aural.html#Emacspeak |
| 08:18 | <hsivonen> | zcorpan: are there other impls besides Emacspeak? |
| 08:18 | <hsivonen> | zcorpan: are there other impls besides Emacspeak? |
| 08:19 | <zcorpan> | hsivonen: dunno |
| 08:19 | <zcorpan> | hsivonen: dunno |
| 08:19 | <zcorpan> | but i hadn't expected that kind of section in css 2.1 |
| 08:20 | <zcorpan> | but i hadn't expected that kind of section in css 2.1 |
| 08:33 | <asmodai> | That's interesting, latest nvidia drivers seem to change something with font look in Firefox. |
| 08:34 | <asmodai> | That's interesting, latest nvidia drivers seem to change something with font look in Firefox. |
| 08:47 | <asmodai> | Mm, restart of firefox cleared that up. Guess it doesn't like having the driver ripped out from underneath it and updated by the recent nvidia installers. |
| 08:47 | <asmodai> | Mm, restart of firefox cleared that up. Guess it doesn't like having the driver ripped out from underneath it and updated by the recent nvidia installers. |
| 08:59 | <loostro> | Hi, is this correct? <a><li>some item</li></a> or I must do <li><a><div>some item</div></a></li> to make sure the anchor covers the whole box? |
| 08:59 | <loostro> | Hi, is this correct? <a><li>some item</li></a> or I must do <li><a><div>some item</div></a></li> to make sure the anchor covers the whole box? |
| 09:07 | <zcorpan> | loostro: neither. you should do <li><a>some item</a></li> and then apply display:block to the link |
| 09:07 | <zcorpan> | loostro: neither. you should do <li><a>some item</a></li> and then apply display:block to the link |
| 09:07 | <loostro> | thx |
| 09:08 | <loostro> | thx |
| 10:24 | zcorpan | finds http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBRFrame.cpp#137 |
| 10:25 | zcorpan | finds http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBRFrame.cpp#137 |
| 10:36 | <Velmont> | Should be more idb people here. Anyone feel called to discuss? :P |
| 10:36 | <Velmont> | Should be more idb people here. Anyone feel called to discuss? :P |
| 10:40 | <smaug____> | Velmont: you need to wait for sicking |
| 10:40 | <smaug____> | Velmont: you need to wait for sicking |
| 10:40 | <jgraham> | Velmont: I thought "idb people" were sicking |
| 10:41 | <jgraham> | Velmont: I thought "idb people" were sicking |
| 10:41 | <jgraham> | And maybe some people at Microsoft, but they're not allowed to hang around here |
| 10:41 | <jgraham> | And maybe some people at Microsoft, but they're not allowed to hang around here |
| 10:44 | <Velmont> | jgraham: Yep, -- but also Jonas from google would be swell to have here. |
| 10:45 | <Velmont> | jgraham: Yep, -- but also Jonas from google would be swell to have here. |
| 10:45 | <Velmont> | smaug____: Yeah yeah, -- I know, but he's not really in my timezone, -- so often not here when I want to talk about stuff :] |
| 10:45 | <Velmont> | smaug____: Hence the "more". |
| 10:45 | <Velmont> | smaug____: Yeah yeah, -- I know, but he's not really in my timezone, -- so often not here when I want to talk about stuff :] |
| 10:45 | <Velmont> | smaug____: Hence the "more". |
| 10:46 | <Velmont> | Don't have to be editor or anything, -- just knowing the spec very well. ;] |
| 10:46 | <Velmont> | Don't have to be editor or anything, -- just knowing the spec very well. ;] |
| 10:46 | <smaug____> | Jonas from google ? |
| 10:46 | <Velmont> | Joshua Bell I meant. |
| 10:46 | <smaug____> | Jonas from google ? |
| 10:46 | <Velmont> | Joshua Bell I meant. |
| 10:46 | <Velmont> | sry :P Talking about Sicking made me write the wrong name. :P |
| 10:47 | <Velmont> | sry :P Talking about Sicking made me write the wrong name. :P |
| 12:16 | <zcorpan> | turns out there were more quirks in the source that weren't documented in mdn http://simon.html5.org/specs/quirks-mode#the-???-quirks |
| 12:16 | <zcorpan> | turns out there were more quirks in the source that weren't documented in mdn http://simon.html5.org/specs/quirks-mode#the-???-quirks |
| 12:20 | <StoneCypher> | why is quirksmode being documented? |
| 12:20 | <StoneCypher> | why is quirksmode being documented? |
| 12:20 | <zcorpan> | http://simon.html5.org/specs/quirks-mode#goals |
| 12:20 | <StoneCypher> | i don't understand the purpose; i thought quirksmode was a grab-bag of browsers trying to DWIM and universally failing |
| 12:20 | <StoneCypher> | well no |
| 12:20 | <StoneCypher> | all that does is say what you're doing |
| 12:20 | <StoneCypher> | not why |
| 12:21 | <zcorpan> | http://simon.html5.org/specs/quirks-mode#goals |
| 12:21 | <StoneCypher> | i don't understand the purpose; i thought quirksmode was a grab-bag of browsers trying to DWIM and universally failing |
| 12:21 | <StoneCypher> | well no |
| 12:21 | <StoneCypher> | all that does is say what you're doing |
| 12:21 | <StoneCypher> | not why |
| 12:21 | <StoneCypher> | i mean yes, i can see that you're documenting quirksmode; the question is why that's desirable. |
| 12:21 | <StoneCypher> | i mean yes, i can see that you're documenting quirksmode; the question is why that's desirable. |
| 12:21 | <zcorpan> | ah. much for the same reason we specified e.g. html parsing |
| 12:21 | <jgraham> | > i thought quirksmode was a grab-bag of browsers trying to DWIM and universally failing |
| 12:21 | <jgraham> | That's where you went wrong |
| 12:22 | <zcorpan> | ah. much for the same reason we specified e.g. html parsing |
| 12:22 | <jgraham> | > i thought quirksmode was a grab-bag of browsers trying to DWIM and universally failing |
| 12:22 | <jgraham> | That's where you went wrong |
| 12:22 | <StoneCypher> | jgraham: okay, so what is it? |
| 12:22 | <annevk> | StoneCypher: "Get interoperability on quirks that are needed for Web compat." seems like a pretty clear "why" |
| 12:22 | <StoneCypher> | jgraham: okay, so what is it? |
| 12:22 | <annevk> | StoneCypher: "Get interoperability on quirks that are needed for Web compat." seems like a pretty clear "why" |
| 12:22 | <StoneCypher> | that's a "what" |
| 12:22 | <StoneCypher> | not a "why" |
| 12:22 | <annevk> | "Limit quirks to a fixed set of legacy features so they don't propagate into new features." too actually |
| 12:22 | <StoneCypher> | those are goals, not purposes. |
| 12:23 | <StoneCypher> | that's a "what" |
| 12:23 | <StoneCypher> | not a "why" |
| 12:23 | <annevk> | "Limit quirks to a fixed set of legacy features so they don't propagate into new features." too actually |
| 12:23 | <StoneCypher> | those are goals, not purposes. |
| 12:23 | <zcorpan> | we want to get interop because it makes sites render the same across browsers, which is good for browser developers not needing to tweak quirks all the time and reverse engineer others, and it's good for users because sites that are written against quirks mode for browser A works the same in browser B |
| 12:24 | <zcorpan> | we want to get interop because it makes sites render the same across browsers, which is good for browser developers not needing to tweak quirks all the time and reverse engineer others, and it's good for users because sites that are written against quirks mode for browser A works the same in browser B |
| 12:24 | <jgraham> | If you don't think that interoperability between browsers is a good enough reason to have a spec, I'm not sure what anyone could say to convince you that standards are a good idea |
| 12:24 | <StoneCypher> | i think we're sort of missing the point of the question |
| 12:24 | <jgraham> | If you don't think that interoperability between browsers is a good enough reason to have a spec, I'm not sure what anyone could say to convince you that standards are a good idea |
| 12:24 | <StoneCypher> | i think we're sort of missing the point of the question |
| 12:24 | <StoneCypher> | it was my understanding that the purpose of quirksmode was to allow browsers to silently fall back to prior, standards violating behavior |
| 12:25 | <StoneCypher> | it was my understanding that the purpose of quirksmode was to allow browsers to silently fall back to prior, standards violating behavior |
| 12:25 | <jgraham> | No |
| 12:25 | <StoneCypher> | so either i misundersatnd what quirksmode is |
| 12:25 | <StoneCypher> | okay, so what is it, i ask again |
| 12:25 | <jgraham> | Many browsers don't have "prior" behaviour |
| 12:25 | <jgraham> | No |
| 12:25 | <StoneCypher> | so either i misundersatnd what quirksmode is |
| 12:25 | <StoneCypher> | okay, so what is it, i ask again |
| 12:25 | <jgraham> | Many browsers don't have "prior" behaviour |
| 12:25 | <jgraham> | They were written after the standard |
| 12:26 | <jgraham> | They were written after the standard |
| 12:26 | <zcorpan> | quirks mode was introduced because the css spec was incompatible with behavior ("quirks") that existing content relied on |
| 12:26 | <zcorpan> | quirks mode was introduced because the css spec was incompatible with behavior ("quirks") that existing content relied on |
| 12:26 | <zcorpan> | instead of fixing css to be compatible |
| 12:26 | <StoneCypher> | zcorpan: i am unable to distinguish between that and what i said |
| 12:26 | <StoneCypher> | zcorpan: what am i missing |
| 12:26 | <jgraham> | The point of quirks mode is to bridge the disconnect that emerged (mostly) in the early days of CSS between what was actually needed to render documents on the web and what the CSS people wrote down |
| 12:26 | <jgraham> | This led to two populations of documents |
| 12:27 | <zcorpan> | instead of fixing css to be compatible |
| 12:27 | <StoneCypher> | zcorpan: i am unable to distinguish between that and what i said |
| 12:27 | <StoneCypher> | zcorpan: what am i missing |
| 12:27 | <jgraham> | The point of quirks mode is to bridge the disconnect that emerged (mostly) in the early days of CSS between what was actually needed to render documents on the web and what the CSS people wrote down |
| 12:27 | <jgraham> | This led to two populations of documents |
| 12:27 | <StoneCypher> | this pretty much sounds like "let the browser violate the standard" |
| 12:27 | <jgraham> | Ones that depended on the new behaiour and ones that depended on the old behaviour |
| 12:27 | <StoneCypher> | this pretty much sounds like "let the browser violate the standard" |
| 12:27 | <jgraham> | Ones that depended on the new behaiour and ones that depended on the old behaviour |
| 12:28 | <jgraham> | Any web browser needs to support both |
| 12:28 | <jgraham> | Any web browser needs to support both |
| 12:28 | <jgraham> | So far only one population has had good implementation instructions |
| 12:28 | <StoneCypher> | so, i respect that there is an art form to talking around the intent of a question |
| 12:28 | <StoneCypher> | but |
| 12:28 | <StoneCypher> | my question stands |
| 12:28 | <StoneCypher> | in what way is that not "let the browsers ignore the standards for old documents" |
| 12:29 | <jgraham> | So far only one population has had good implementation instructions |
| 12:29 | <StoneCypher> | so, i respect that there is an art form to talking around the intent of a question |
| 12:29 | <StoneCypher> | but |
| 12:29 | <StoneCypher> | my question stands |
| 12:29 | <StoneCypher> | in what way is that not "let the browsers ignore the standards for old documents" |
| 12:29 | <jgraham> | I think you are making the erroneous assumption that calling something a "standard" makes it magical |
| 12:29 | <StoneCypher> | i didn't say anything about magic |
| 12:30 | <jgraham> | I think you are making the erroneous assumption that calling something a "standard" makes it magical |
| 12:30 | <StoneCypher> | i didn't say anything about magic |
| 12:30 | <annevk> | o_O |
| 12:30 | <annevk> | o_O |
| 12:30 | <jgraham> | OK then, let me rephrase |
| 12:30 | <jgraham> | The point of the document is the exact opposite of what you say |
| 12:31 | <jgraham> | OK then, let me rephrase |
| 12:31 | <jgraham> | The point of the document is the exact opposite of what you say |
| 12:31 | <jgraham> | It is "create a standard for rendering old (or indeed new, if they happen to have a particular pragma) documents" |
| 12:31 | <StoneCypher> | oh. |
| 12:31 | <jgraham> | It is "create a standard for rendering old (or indeed new, if they happen to have a particular pragma) documents" |
| 12:31 | <StoneCypher> | oh. |
| 12:31 | <StoneCypher> | well that was straightforward. |
| 12:31 | <StoneCypher> | thakn you. |
| 12:32 | <StoneCypher> | well that was straightforward. |
| 12:32 | <StoneCypher> | thakn you. |
| 12:32 | <StoneCypher> | are you open to small suggestions? |
| 12:32 | <zcorpan> | is there something i should add to the spec, like a section "Motivation" that discusses this? |
| 12:32 | <zcorpan> | sure |
| 12:32 | <StoneCypher> | are you open to small suggestions? |
| 12:32 | <zcorpan> | is there something i should add to the spec, like a section "Motivation" that discusses this? |
| 12:32 | <zcorpan> | sure |
| 12:32 | <StoneCypher> | that's what i was about to suggest, actually :) |
| 12:32 | <StoneCypher> | people from standards-focussed languages (in my case, c++) will read those goals in the way that i did, i believe |
| 12:32 | <StoneCypher> | adding a statement of purpose will clarify what one wants here |
| 12:33 | <StoneCypher> | that's what i was about to suggest, actually :) |
| 12:33 | <StoneCypher> | people from standards-focussed languages (in my case, c++) will read those goals in the way that i did, i believe |
| 12:33 | <StoneCypher> | adding a statement of purpose will clarify what one wants here |
| 12:33 | <StoneCypher> | a bullet added to those goals, basically a cut and paste of jgraham's last sentence, will reach dim people like me quite quickly |
| 12:33 | <zcorpan> | is what jgraham wrote good enough for the spec or should it be phrased in some different way? |
| 12:33 | <StoneCypher> | a bullet added to those goals, basically a cut and paste of jgraham's last sentence, will reach dim people like me quite quickly |
| 12:33 | <zcorpan> | is what jgraham wrote good enough for the spec or should it be phrased in some different way? |
| 12:33 | <zcorpan> | k |
| 12:33 | <StoneCypher> | other than rephrasing to fit the style of the doc, it's near-ideal |
| 12:33 | <StoneCypher> | jgraham: apologies if i was being dense. i really didn't get it until then. |
| 12:34 | <zcorpan> | k |
| 12:34 | <StoneCypher> | other than rephrasing to fit the style of the doc, it's near-ideal |
| 12:34 | <StoneCypher> | jgraham: apologies if i was being dense. i really didn't get it until then. |
| 12:35 | <kennyluck> | (re. So far only one population has had good implementation instructions) Because no one bother care the other population which doesn't grow. |
| 12:36 | <kennyluck> | (re. So far only one population has had good implementation instructions) Because no one bother care the other population which doesn't grow. |
| 12:36 | <StoneCypher> | is the idea to solidify the handling of legacy documents, or are people (not counting people who just don't know any better, say code cut and pasters) actually still using quirksmode on purpose? |
| 12:36 | <kennyluck> | It's fair to say the quirks mode documentation a worthwhile document (so other people don't need to reverse engineer, indeed), though I doubt we will actually reach interop for this population. |
| 12:37 | <StoneCypher> | is the idea to solidify the handling of legacy documents, or are people (not counting people who just don't know any better, say code cut and pasters) actually still using quirksmode on purpose? |
| 12:37 | <kennyluck> | It's fair to say the quirks mode documentation a worthwhile document (so other people don't need to reverse engineer, indeed), though I doubt we will actually reach interop for this population. |
| 12:37 | <StoneCypher> | i agree, now that i know what it's for |
| 12:37 | <StoneCypher> | i agree, now that i know what it's for |
| 12:37 | <kennyluck> | And I don't think it makes to the Web better if reaching interop for this population actually makes the browsers slower. |
| 12:37 | <StoneCypher> | well, if browsers are well authored, it shouldn't |
| 12:38 | <kennyluck> | And I don't think it makes to the Web better if reaching interop for this population actually makes the browsers slower. |
| 12:38 | <StoneCypher> | well, if browsers are well authored, it shouldn't |
| 12:38 | <StoneCypher> | things that kick in in quirksmode have no need to be in the mainline path of control |
| 12:38 | <StoneCypher> | things that kick in in quirksmode have no need to be in the mainline path of control |
| 12:42 | <jgraham> | kennyluck: I don't think it's either true that it doesn't grow or that people don't care. I thoroughly expect that Opera has site-compat bugs related to slight differences in quirks mode |
| 12:43 | <jgraham> | kennyluck: I don't think it's either true that it doesn't grow or that people don't care. I thoroughly expect that Opera has site-compat bugs related to slight differences in quirks mode |
| 12:43 | <jgraham> | and users don't exactly check the doctype and decide "oh the site depends on undefined behaviour. I should stop using the site rather than switch browser" |
| 12:43 | <jgraham> | and users don't exactly check the doctype and decide "oh the site depends on undefined behaviour. I should stop using the site rather than switch browser" |
| 12:43 | <jgraham> | Especially if it e.g. their bank |
| 12:43 | <kennyluck> | That's true. |
| 12:43 | <zcorpan> | ok i added what jgraham said verbatim to Goals. thanks |
| 12:44 | <jgraham> | Especially if it e.g. their bank |
| 12:44 | <kennyluck> | That's true. |
| 12:44 | <zcorpan> | ok i added what jgraham said verbatim to Goals. thanks |
| 12:47 | <ard_> | hi. what should I do if I'd like to see something added to http://wiki.whatwg.org/wiki/Canvas (new api proposals) ? |
| 12:47 | <ard_> | hi. what should I do if I'd like to see something added to http://wiki.whatwg.org/wiki/Canvas (new api proposals) ? |
| 12:50 | <kennyluck> | Anyway, I would probably not call this document "Quirks Mode Standards" but something like "Quirks Mode Interoperability Living Document" or "CSS LS — Appendix X. Quirks Mode (This section in non-normative)". |
| 12:50 | <kennyluck> | Anyway, I would probably not call this document "Quirks Mode Standards" but something like "Quirks Mode Interoperability Living Document" or "CSS LS — Appendix X. Quirks Mode (This section in non-normative)". |
| 12:51 | <StoneCypher> | zcorpan: word |
| 12:51 | <StoneCypher> | zcorpan: word |
| 12:51 | <StoneCypher> | zcorpan, jgraham, annevk: thank you for the discussion |
| 12:51 | <StoneCypher> | i feel like i forgot someone |
| 12:52 | <StoneCypher> | zcorpan, jgraham, annevk: thank you for the discussion |
| 12:52 | <StoneCypher> | i feel like i forgot someone |
| 12:53 | <annevk> | ard_: at this point it's prolly best to email |
| 12:54 | <annevk> | ard_: at this point it's prolly best to email |
| 12:54 | <ard_> | annevk: hixie? |
| 12:54 | <annevk> | ard_: and it's best to email about use cases, not solutions |
| 12:54 | <annevk> | ard_: whatwg⊙wo |
| 12:54 | <annevk> | ard_: you need to be subscribed first |
| 12:54 | <ard_> | annevk: hixie? |
| 12:54 | <annevk> | ard_: and it's best to email about use cases, not solutions |
| 12:54 | <annevk> | ard_: whatwg⊙wo |
| 12:54 | <annevk> | ard_: you need to be subscribed first |
| 12:56 | <ard_> | annevk: I'll try. thanks :) |
| 12:57 | <ard_> | annevk: I'll try. thanks :) |
| 13:05 | <matjas> | “'background' on the root element is rendered on the canvas. @SelenIT2 and less surprisingly @davidbaron and @zcorpan had this. #csspubquiz” — http://twitter.com/annevk/status/180277920072351745 mind explaining? |
| 13:05 | <matjas> | i have a feeling this is not just about <style>:root { background: lime; }</style> |
| 13:05 | <matjas> | “'background' on the root element is rendered on the canvas. @SelenIT2 and less surprisingly @davidbaron and @zcorpan had this. #csspubquiz” — http://twitter.com/annevk/status/180277920072351745 mind explaining? |
| 13:05 | <matjas> | i have a feeling this is not just about <style>:root { background: lime; }</style> |
| 13:07 | <kennyluck> | "I didn't expect spec comment handling to turn into Validator.nu feature bargaining." |
| 13:08 | <kennyluck> | "I didn't expect spec comment handling to turn into Validator.nu feature bargaining." |
| 13:08 | <StoneCypher> | lal |
| 13:08 | <MikeSmith> | kennyluck: what you quoting from? |
| 13:08 | <StoneCypher> | lal |
| 13:08 | <MikeSmith> | kennyluck: what you quoting from? |
| 13:08 | <kennyluck> | MikeSmith, https://www.w3.org/Bugs/Public/show_bug.cgi?id=15936#c4 |
| 13:09 | <kennyluck> | MikeSmith, https://www.w3.org/Bugs/Public/show_bug.cgi?id=15936#c4 |
| 13:16 | <matjas> | re: root background (http://www.w3.org/TR/CSS21/colors.html#background), what exactly fails in all browsers except IE/Opera? |
| 13:17 | <matjas> | re: root background (http://www.w3.org/TR/CSS21/colors.html#background), what exactly fails in all browsers except IE/Opera? |
| 13:20 | <annevk> | matjas: you forgot display:none |
| 13:21 | <annevk> | matjas: you forgot display:none |
| 13:21 | <annevk> | matjas: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cstyle%3E%3Aroot%7Bdisplay%3Anone%3Bbackground%3Alime%7D%3C%2Fstyle%3E |
| 13:21 | <annevk> | matjas: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cstyle%3E%3Aroot%7Bdisplay%3Anone%3Bbackground%3Alime%7D%3C%2Fstyle%3E |
| 13:21 | <matjas> | annevk: oh wow! thanks |
| 13:22 | <matjas> | annevk: oh wow! thanks |
| 13:22 | <annevk> | tweet is a little ambiguous because of length |
| 13:22 | <annevk> | everyone renders it on canvas |
| 13:22 | <annevk> | but gecko/webkit don't when display:none |
| 13:23 | <annevk> | tweet is a little ambiguous because of length |
| 13:23 | <annevk> | everyone renders it on canvas |
| 13:23 | <annevk> | but gecko/webkit don't when display:none |
| 13:23 | <annevk> | they prolly simple don't look at background |
| 13:23 | <annevk> | they prolly simple don't look at background |
| 13:23 | <annevk> | yeah |
| 13:23 | <annevk> | Gecko has the same bug for body{display:none;background:lime} |
| 13:24 | <annevk> | yeah |
| 13:24 | <annevk> | Gecko has the same bug for body{display:none;background:lime} |
| 13:24 | <annevk> | WebKit too |
| 13:24 | <annevk> | (body elements in the HTML namespace get their background property propagated too) |
| 13:25 | <annevk> | (body elements in the HTML namespace get their background property propagated too) |
| 13:29 | <matjas> | annevk: where does it say that about `body`? is that defined by CSS or HTML? |
| 13:30 | <matjas> | annevk: where does it say that about `body`? is that defined by CSS or HTML? |
| 13:30 | matjas | geeks out on these obscure fun facts |
| 13:30 | <annevk> | CSS |
| 13:30 | matjas | geeks out on these obscure fun facts |
| 13:30 | <annevk> | CSS |
| 13:30 | <annevk> | http://www.w3.org/TR/CSS21/colors.html#background |
| 13:30 | <matjas> | “ For documents whose root element is an HTML "HTML" element or an XHTML "html" element that has computed values of 'transparent' for 'background-color' and 'none' for 'background-image', user agents must instead use the computed value of the background properties from that element's first HTML "BODY" element or XHTML "body" element child when painting backgrounds for the canvas, and must not pa |
| 13:31 | <annevk> | http://www.w3.org/TR/CSS21/colors.html#background |
| 13:31 | <matjas> | int a background for that child element.” |
| 13:31 | <annevk> | fourth paragraph |
| 13:31 | <matjas> | “ For documents whose root element is an HTML "HTML" element or an XHTML "html" element that has computed values of 'transparent' for 'background-color' and 'none' for 'background-image', user agents must instead use the computed value of the background properties from that element's first HTML "BODY" element or XHTML "body" element child when painting backgrounds for the canvas, and must not pa |
| 13:31 | <matjas> | int a background for that child element.” |
| 13:31 | <annevk> | fourth paragraph |
| 13:31 | <matjas> | right |
| 13:31 | <matjas> | mind = blown |
| 13:31 | <matjas> | right |
| 13:31 | <annevk> | http://www.w3.org/TR/CSS21/visufx.html#overflow has the same |
| 13:31 | <matjas> | mind = blown |
| 13:31 | <annevk> | http://www.w3.org/TR/CSS21/visufx.html#overflow has the same |
| 13:36 | <matjas> | ah, i remember being confused by that a couple of years ago, in a design that required `body { overflow: auto }` |
| 13:36 | <matjas> | ah, i remember being confused by that a couple of years ago, in a design that required `body { overflow: auto }` |
| 13:37 | <zcorpan> | annevk: alert() didn't count as a correct answer? :-) |
| 13:37 | <zcorpan> | annevk: alert() didn't count as a correct answer? :-) |
| 13:37 | <kennyluck> | annevk, should that actually include <frameset> to match document.body ? |
| 13:37 | kennyluck | was thinking about this today. |
| 13:37 | <zcorpan> | no |
| 13:38 | <kennyluck> | annevk, should that actually include <frameset> to match document.body ? |
| 13:38 | kennyluck | was thinking about this today. |
| 13:38 | <zcorpan> | no |
| 13:38 | <kennyluck> | I haven't tested it, but that's a bit surprising. Anyway. |
| 13:39 | <kennyluck> | I haven't tested it, but that's a bit surprising. Anyway. |
| 13:39 | <jgraham> | That is like the fourth time matjas has said "mind = blown" in here recently. Does someone keep scraping the bits off the wall and reassembling them? |
| 13:39 | <jgraham> | That is like the fourth time matjas has said "mind = blown" in here recently. Does someone keep scraping the bits off the wall and reassembling them? |
| 13:39 | <matjas> | jgraham: probably not worth it |
| 13:40 | <matjas> | jgraham: probably not worth it |
| 14:09 | <Philip`> | Hmph, it looks like people have started doing animated ads with HTML instead of Flash now, so I can't trivially block them :-( |
| 14:10 | <Philip`> | Hmph, it looks like people have started doing animated ads with HTML instead of Flash now, so I can't trivially block them :-( |
| 14:11 | <StoneCypher> | yeah, when you try to starve sites of the revenue that makes them run, they fight you. |
| 14:12 | <bga> | Philip` * { animation: none !important } ? |
| 14:13 | <bga> | Philip` * { animation: none !important } ? |
| 14:13 | <StoneCypher> | :/ |
| 14:13 | <StoneCypher> | :/ |
| 14:13 | <webben> | Philip`: Really? Got an example? |
| 14:14 | <webben> | Philip`: Really? Got an example? |
| 14:14 | <Philip`> | bga: It's not CSS animation, it's just JS moving things around |
| 14:15 | <Philip`> | bga: It's not CSS animation, it's just JS moving things around |
| 14:15 | <bga> | ah. i disabled js in browser so never see it |
| 14:16 | <bga> | ah. i disabled js in browser so never see it |
| 14:16 | <Philip`> | webben: http://www.eurogamer.net/ (especially the "This weeks [sic] top games" on the right of the page, which is very distracting when trying to read any nearby text) (don't know if the ads are location-dependent) |
| 14:16 | <Philip`> | webben: http://www.eurogamer.net/ (especially the "This weeks [sic] top games" on the right of the page, which is very distracting when trying to read any nearby text) (don't know if the ads are location-dependent) |
| 14:19 | <annevk> | argh |
| 14:19 | <annevk> | why does IE not support overrideMimeType |
| 14:20 | <annevk> | argh |
| 14:20 | <annevk> | why does IE not support overrideMimeType |
| 14:20 | <Workshiva> | That would require supporting mime types to begin with :P |
| 14:20 | <Workshiva> | That would require supporting mime types to begin with :P |
| 14:20 | <bga> | annevk for what? |
| 14:20 | <bga> | binary data hack? |
| 14:20 | <annevk> | Workshiva: haha just dropping in at the appropriate times huh? |
| 14:21 | <bga> | annevk for what? |
| 14:21 | <bga> | binary data hack? |
| 14:21 | <annevk> | Workshiva: haha just dropping in at the appropriate times huh? |
| 14:21 | <annevk> | bga: testing euc-jp without much of a server |
| 14:21 | <annevk> | bga: testing euc-jp without much of a server |
| 14:22 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1400 intredasting |
| 14:22 | <Workshiva> | I'm always here, just not saying anything |
| 14:22 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1400 intredasting |
| 14:22 | <Workshiva> | I'm always here, just not saying anything |
| 14:25 | <Velmont> | Bah, -- firefox doesn't fire success event after upgradeneeded after a second opening of a datababase. It seems very wrong, -- but I'm not sure if I did something wrong in the test. |
| 14:25 | <Velmont> | Bah, -- firefox doesn't fire success event after upgradeneeded after a second opening of a datababase. It seems very wrong, -- but I'm not sure if I did something wrong in the test. |
| 14:37 | <annevk> | well well |
| 14:37 | <annevk> | maybe I don't need to test IE |
| 14:38 | <annevk> | well well |
| 14:38 | <annevk> | maybe I don't need to test IE |
| 14:38 | <annevk> | for valid multi-octet sequences in euc-jp there's agreement between Chrome, Opera, and Firefox |
| 14:38 | <annevk> | for valid multi-octet sequences in euc-jp there's agreement between Chrome, Opera, and Firefox |
| 14:43 | <MikeSmith> | annevk: btw we need tests for sandbox allow-popups behavior |
| 14:43 | <MikeSmith> | just sayin |
| 14:43 | <MikeSmith> | webkit and IE have both implemented it |
| 14:43 | <MikeSmith> | without a spec |
| 14:44 | <MikeSmith> | annevk: btw we need tests for sandbox allow-popups behavior |
| 14:44 | <MikeSmith> | just sayin |
| 14:44 | <MikeSmith> | webkit and IE have both implemented it |
| 14:44 | <MikeSmith> | without a spec |
| 14:44 | <MikeSmith> | so in order to make a proper spec we need to test it and see what we find |
| 14:45 | <MikeSmith> | so in order to make a proper spec we need to test it and see what we find |
| 14:45 | <MikeSmith> | jgraham: ↑ |
| 14:45 | <annevk> | i'm not doing much with sandbox |
| 14:45 | <MikeSmith> | jgraham: ↑ |
| 14:45 | <annevk> | i'm not doing much with sandbox |
| 14:45 | <annevk> | ideally webkit/ie contribute some tests |
| 14:45 | <MikeSmith> | yeah |
| 14:45 | <MikeSmith> | but to be clear the spec work is blocked on that |
| 14:46 | <annevk> | ideally webkit/ie contribute some tests |
| 14:46 | <MikeSmith> | yeah |
| 14:46 | <MikeSmith> | but to be clear the spec work is blocked on that |
| 14:46 | <MikeSmith> | Hixie needs data in order to actually spec it out |
| 14:47 | <MikeSmith> | Hixie needs data in order to actually spec it out |
| 14:47 | <MikeSmith> | and I can write the tests myself if I need to I guess |
| 14:47 | <MikeSmith> | but really |
| 14:47 | <MikeSmith> | and I can write the tests myself if I need to I guess |
| 14:47 | <MikeSmith> | but really |
| 14:47 | <annevk> | oh did I make a comment about allow-popups somewhere? |
| 14:47 | <MikeSmith> | no, not you personally |
| 14:48 | <annevk> | oh did I make a comment about allow-popups somewhere? |
| 14:48 | <MikeSmith> | no, not you personally |
| 14:48 | <annevk> | my email to WHATWG was about script-opened links, unrelated to sandboxing |
| 14:48 | <annevk> | my email to WHATWG was about script-opened links, unrelated to sandboxing |
| 14:49 | <MikeSmith> | my point is, when vendors unilaterally choose to implement something that's not in the spec, the least they can do is to provide cross-browser test cases for that feature |
| 14:49 | <MikeSmith> | my point is, when vendors unilaterally choose to implement something that's not in the spec, the least they can do is to provide cross-browser test cases for that feature |
| 14:50 | <MikeSmith> | because at this point it's yet another case of, We implemented this, now Hixie has to reverse-engineer what we implemented and make a spec for it |
| 14:50 | <MikeSmith> | because at this point it's yet another case of, We implemented this, now Hixie has to reverse-engineer what we implemented and make a spec for it |
| 14:50 | <MikeSmith> | which is fucktarded |
| 14:50 | <annevk> | no disagreement there :) |
| 14:51 | <MikeSmith> | which is fucktarded |
| 14:51 | <annevk> | no disagreement there :) |
| 14:51 | <jgraham> | MikeSmith: fucktarded it may be, but it is the traditional mode of operation :( |
| 14:51 | <jgraham> | MikeSmith: fucktarded it may be, but it is the traditional mode of operation :( |
| 14:51 | <MikeSmith> | yeah well |
| 14:51 | <MikeSmith> | it obviously doesn't scale |
| 14:52 | <MikeSmith> | yeah well |
| 14:52 | <MikeSmith> | it obviously doesn't scale |
| 14:52 | <MikeSmith> | one dude cannot be expected to single-handedly do that work |
| 14:52 | <MikeSmith> | one dude cannot be expected to single-handedly do that work |
| 14:52 | <jgraham> | In related news, the facebook mobile test thing that everyone got excited about links to a "feature" that has a Safari blog post for the "spec" |
| 14:53 | <jgraham> | In related news, the facebook mobile test thing that everyone got excited about links to a "feature" that has a Safari blog post for the "spec" |
| 14:54 | <MikeSmith> | jgraham: eh? |
| 14:54 | <MikeSmith> | which one? |
| 14:55 | <MikeSmith> | jgraham: eh? |
| 14:55 | <MikeSmith> | which one? |
| 14:55 | <MikeSmith> | if that is the case, talk to Rick Waldron and have it fixed |
| 14:55 | <jgraham> | http://www.webkit.org/blog/176/css-canvas-drawing/ |
| 14:56 | <jgraham> | http://www.webkit.org/blog/176/css-canvas-drawing/ |
| 14:56 | <MikeSmith> | jgraham: and_ |
| 14:56 | <MikeSmith> | jgraham: and? |
| 14:57 | <MikeSmith> | jgraham: and_ |
| 14:57 | <MikeSmith> | jgraham: and? |
| 14:58 | <jgraham> | MikeSmith: You asked which one. That one. |
| 14:58 | <jgraham> | Is there an actual spec for that? |
| 14:58 | <jgraham> | If so the test should link to it |
| 14:59 | <jgraham> | MikeSmith: You asked which one. That one. |
| 14:59 | <jgraham> | Is there an actual spec for that? |
| 14:59 | <jgraham> | If so the test should link to it |
| 14:59 | <jgraham> | Anyway it's hardly the only problem with that test |
| 14:59 | <jgraham> | Anyway it's hardly the only problem with that test |
| 14:59 | <jgraham> | I thought maybe the Mobile Web Community Group were supposed to talk about this sort of thing but so far we had an argument about whether ipads are the only tablets |
| 15:00 | <jgraham> | I thought maybe the Mobile Web Community Group were supposed to talk about this sort of thing but so far we had an argument about whether ipads are the only tablets |
| 15:00 | <jgraham> | Sorry "Core Mobile Web Platform" |
| 15:00 | <jgraham> | Sorry "Core Mobile Web Platform" |
| 15:00 | <jgraham> | And afaik the code is still unreleased |
| 15:00 | <beverloo> | MikeSmith, already talked to him previously |
| 15:00 | <jgraham> | Although thegh do seem to have helpfully minimised the test code so its even harder to read than it was before |
| 15:00 | <beverloo> | it's intentional |
| 15:01 | <jgraham> | And afaik the code is still unreleased |
| 15:01 | <beverloo> | MikeSmith, already talked to him previously |
| 15:01 | <beverloo> | the test should "demonstrate what is relevant for authors" |
| 15:01 | <jgraham> | Although thegh do seem to have helpfully minimised the test code so its even harder to read than it was before |
| 15:01 | <beverloo> | it's intentional |
| 15:01 | <beverloo> | the test should "demonstrate what is relevant for authors" |
| 15:01 | <jgraham> | I would like to find out who these authors are, exactly |
| 15:02 | <jgraham> | I would like to find out who these authors are, exactly |
| 15:02 | <MikeSmith> | beverloo: OK |
| 15:02 | <jgraham> | Although you would hope that something authors were actually clammering for would have gone from blogpost to draft spec in < 4 years |
| 15:03 | <MikeSmith> | beverloo: OK |
| 15:03 | <jgraham> | Although you would hope that something authors were actually clammering for would have gone from blogpost to draft spec in < 4 years |
| 15:06 | <jgraham> | (In case anyone is listening and so that I can refer to the list later, rng.io also seems to be very confused about the perspective property, really really like Blobs and BlobBuilder - which will die, encourage implementation of old or prefixed forms, and have a really stupid scoring system) |
| 15:06 | <jgraham> | (there is probably more) |
| 15:06 | <jgraham> | (In case anyone is listening and so that I can refer to the list later, rng.io also seems to be very confused about the perspective property, really really like Blobs and BlobBuilder - which will die, encourage implementation of old or prefixed forms, and have a really stupid scoring system) |
| 15:06 | <jgraham> | (there is probably more) |
| 15:08 | <jgraham> | (oh and it suggests implementing the details element, which I think should be gated on the WebComponents work, which isn't featured) |
| 15:08 | <jgraham> | (oh and it suggests implementing the details element, which I think should be gated on the WebComponents work, which isn't featured) |
| 15:26 | <annevk> | preferences on how to display what is essentially a sparse array? (extended jis208) |
| 15:27 | <annevk> | preferences on how to display what is essentially a sparse array? (extended jis208) |
| 15:27 | <annevk> | I'm thinking something like |
| 15:27 | <annevk> | 0210 0xFF17 #textual representation of code point |
| 15:28 | <annevk> | I'm thinking something like |
| 15:28 | <annevk> | 0210 0xFF17 #textual representation of code point |
| 15:28 | <annevk> | so 4-digit index, tab, code point, tab, comment |
| 15:28 | <annevk> | index in decimal |
| 15:28 | <annevk> | so 4-digit index, tab, code point, tab, comment |
| 15:28 | <annevk> | index in decimal |
| 15:28 | <annevk> | index skips FFFD segments |
| 15:29 | <annevk> | index skips FFFD segments |
| 15:30 | <annevk> | per usual nobody cares? |
| 15:30 | <annevk> | in a kingdom of one... |
| 15:30 | <annevk> | per usual nobody cares? |
| 15:30 | <annevk> | in a kingdom of one... |
| 15:39 | <Hixie> | MikeSmith: to be fair, two implementors implemented it (so it wasn't unilateral) and they did so after asking me to spec it (so it's not their fault there was no spec; i probably told them to give us an experimental implementation) |
| 15:40 | <Hixie> | MikeSmith: to be fair, two implementors implemented it (so it wasn't unilateral) and they did so after asking me to spec it (so it's not their fault there was no spec; i probably told them to give us an experimental implementation) |
| 15:40 | <StoneCypher> | Hixie: i just found out you also like The One True Tool |
| 15:41 | <StoneCypher> | Hixie: i just found out you also like The One True Tool |
| 15:41 | <StoneCypher> | Hixie: so a beer for you if we're ever in the same city |
| 15:41 | <StoneCypher> | Hixie: so a beer for you if we're ever in the same city |
| 15:41 | StoneCypher | <3 princexml |
| 15:41 | StoneCypher | <3 princexml |
| 15:41 | <Hixie> | i don't drink :-P |
| 15:41 | <StoneCypher> | a coffee? |
| 15:41 | <StoneCypher> | ok. |
| 15:41 | <Hixie> | i don't do any drugs :-P |
| 15:42 | <Hixie> | i don't drink :-P |
| 15:42 | <jgraham> | StoneCypher: You should move rapidly to water |
| 15:42 | <StoneCypher> | a coffee? |
| 15:42 | <StoneCypher> | ok. |
| 15:42 | <Hixie> | i don't do any drugs :-P |
| 15:42 | <jgraham> | StoneCypher: You should move rapidly to water |
| 15:42 | <jgraham> | Hixie is a cheap date |
| 15:42 | <jgraham> | ;) |
| 15:42 | <Hixie> | good fruit juices are more expensive than beer |
| 15:42 | <jgraham> | Hixie is a cheap date |
| 15:42 | <StoneCypher> | Hixie: An undefined desirable social beverage outing for you |
| 15:42 | <jgraham> | ;) |
| 15:42 | <Hixie> | good fruit juices are more expensive than beer |
| 15:42 | <StoneCypher> | Hixie: An undefined desirable social beverage outing for you |
| 15:42 | <StoneCypher> | <hixie> I don't consume liquids |
| 15:43 | <StoneCypher> | <hixie> I don't consume liquids |
| 15:43 | <StoneCypher> | point is, i just wanted to hurrah princexml fans |
| 15:43 | <jgraham> | Hixie: Not sure what constitues good, but that is mildly surprising (and almost certainly not true in scandinavia) |
| 15:43 | <StoneCypher> | point is, i just wanted to hurrah princexml fans |
| 15:43 | <jgraham> | Hixie: Not sure what constitues good, but that is mildly surprising (and almost certainly not true in scandinavia) |
| 15:43 | <jgraham> | (I'm mildly surprised it is true in california given the climate) |
| 15:43 | <StoneCypher> | jgraham: it is in areas where shipping is the dominant cost, because coffee beans weigh little |
| 15:44 | <jgraham> | (I'm mildly surprised it is true in california given the climate) |
| 15:44 | <StoneCypher> | jgraham: it is in areas where shipping is the dominant cost, because coffee beans weigh little |
| 15:44 | <StoneCypher> | also shelf space costs, etc |
| 15:44 | <StoneCypher> | also shelf space costs, etc |
| 15:44 | <jgraham> | I sort of imagine that in california you buy the fruit juice from organic farmer's markets |
| 15:45 | <jgraham> | I sort of imagine that in california you buy the fruit juice from organic farmer's markets |
| 15:45 | <StoneCypher> | i go to a good farmer's market and they never have juices other than cider there |
| 15:45 | <jgraham> | But maybe we are comparing the price of good fruit juice in a pub/resturant to bad beer in the same establishment |
| 15:45 | <StoneCypher> | i go to a good farmer's market and they never have juices other than cider there |
| 15:45 | <jgraham> | But maybe we are comparing the price of good fruit juice in a pub/resturant to bad beer in the same establishment |
| 15:45 | <StoneCypher> | i think he meant at a juice bar like odwalla or jamba juice |
| 15:46 | <StoneCypher> | i think he meant at a juice bar like odwalla or jamba juice |
| 15:47 | <Hixie> | jgraham: how much would freshly pressed kiwi juice cost at your local bar, and how much would the same volume of your favourite beer cost? |
| 15:47 | <Hixie> | jgraham: how much would freshly pressed kiwi juice cost at your local bar, and how much would the same volume of your favourite beer cost? |
| 15:48 | <jgraham> | Since I don't drink beer… (or alcohol in general) |
| 15:49 | <jgraham> | Since I don't drink beer… (or alcohol in general) |
| 15:49 | <jgraham> | I'm not sure one can get fresh pressed kizi juice easilly here |
| 15:49 | <annevk> | my favorite beer in Sweden prolly costs more |
| 15:49 | <jgraham> | *kiwi |
| 15:49 | <annevk> | at least last time it was about EUR 20 |
| 15:49 | <jgraham> | I'm not sure one can get fresh pressed kizi juice easilly here |
| 15:49 | <annevk> | my favorite beer in Sweden prolly costs more |
| 15:49 | <jgraham> | *kiwi |
| 15:49 | <annevk> | at least last time it was about EUR 20 |
| 15:49 | <annevk> | you should be able to get kiwi juice for less :) |
| 15:50 | <annevk> | you should be able to get kiwi juice for less :) |
| 15:50 | <Hixie> | jgraham: the cost would involve paying someone to go buy some kiwis, skin them, and press them, and it takes a _lot_ of kiwis for a pint. and kiwis aren't cheap. |
| 15:50 | <annevk> | hmm yeah |
| 15:50 | <Hixie> | but anyway |
| 15:50 | <annevk> | :) |
| 15:50 | <annevk> | hmm yeah |
| 15:50 | <Hixie> | but anyway |
| 15:50 | <annevk> | :) |
| 15:51 | <jgraham> | I might accept that per ml kiwi juice is more expensive than many beers. |
| 15:51 | <Hixie> | my point is just that fruit juices, when treated the same way as other beverages, no longer seem like the "cheap" option |
| 15:51 | <jgraham> | I might accept that per ml kiwi juice is more expensive than many beers. |
| 15:51 | <jgraham> | (you probably want to drink less fruit juice though) |
| 15:51 | <Hixie> | my point is just that fruit juices, when treated the same way as other beverages, no longer seem like the "cheap" option |
| 15:51 | <jgraham> | (you probably want to drink less fruit juice though) |
| 15:52 | <matjas> | annevk: “strangely Firefox does it using "visibility: hidden", Opera accepts both ways, Safari/Chrome accepts none” — http://twitter.com/diegoperini/status/180320317238034432 interesting |
| 15:52 | <matjas> | annevk: “strangely Firefox does it using "visibility: hidden", Opera accepts both ways, Safari/Chrome accepts none” — http://twitter.com/diegoperini/status/180320317238034432 interesting |
| 15:57 | <annevk> | matjas: presumably because when you use visibility, layout still happens |
| 15:57 | <annevk> | matjas: presumably because when you use visibility, layout still happens |
| 15:57 | <annevk> | matjas: whereas with display:none you don't generate a box and as optimization you can skip stuff (and they prolly skip applying background incorrectly) |
| 15:58 | <annevk> | matjas: whereas with display:none you don't generate a box and as optimization you can skip stuff (and they prolly skip applying background incorrectly) |
| 15:58 | <annevk> | but you know, that's guessing about implementation details |
| 15:58 | <annevk> | but you know, that's guessing about implementation details |
| 16:01 | <annevk> | ooh |
| 16:01 | <annevk> | jis212 is not entirely interoperable |
| 16:02 | <annevk> | ooh |
| 16:02 | <annevk> | jis212 is not entirely interoperable |
| 16:02 | <annevk> | one minor difference between Opera and Gecko, and a dozen or so between Opera/Gecko and Chrome |
| 16:02 | <annevk> | one minor difference between Opera and Gecko, and a dozen or so between Opera/Gecko and Chrome |
| 16:02 | <annevk> | well 20 |
| 16:03 | <annevk> | well 20 |
| 16:03 | <annevk> | aah |
| 16:04 | <annevk> | aah |
| 16:04 | <annevk> | difference between Opera and Gecko/Chrome is that Opera emits a normal tilde whereas Gecko/Chrome emit a fullwidth tilde |
| 16:04 | <annevk> | difference between Opera and Gecko/Chrome is that Opera emits a normal tilde whereas Gecko/Chrome emit a fullwidth tilde |
| 16:08 | <Velmont> | Nice discussion on drinks and stuff. -- I find it hard to find good, interesting stuff in bars etc since I don't really drink alcohol. |
| 16:08 | <Velmont> | Nice discussion on drinks and stuff. -- I find it hard to find good, interesting stuff in bars etc since I don't really drink alcohol. |
| 16:08 | <Velmont> | Some places has exotic non-alcoholic beer, so I take that, -- but there's very little fruit juice going on. Normally only some sour non-fresh orange juice which I most decidedly don't want. |
| 16:09 | <Velmont> | Some places has exotic non-alcoholic beer, so I take that, -- but there's very little fruit juice going on. Normally only some sour non-fresh orange juice which I most decidedly don't want. |
| 16:09 | <Velmont> | But having real fresh stuff would be A+. I'd take that. |
| 16:09 | <jgraham> | I imagine that one advantage of living in California is that they actually have fruit |
| 16:09 | <annevk> | I never get much further than bitter lemon / tonic / cola in a bar |
| 16:09 | <Velmont> | But having real fresh stuff would be A+. I'd take that. |
| 16:09 | <jgraham> | I imagine that one advantage of living in California is that they actually have fruit |
| 16:09 | <annevk> | I never get much further than bitter lemon / tonic / cola in a bar |
| 16:09 | <annevk> | but then I like beer too |
| 16:10 | <annevk> | but then I like beer too |
| 16:10 | <jgraham> | Well, we have fruit too; Apples in the autum, strawberries for 2 weeks, raspberries for two weeks and blueberries for a while |
| 16:10 | <Velmont> | Yes, California > Norway there I guess ;-) |
| 16:10 | <jgraham> | It doesn't seem to be enough to have a fruit-based drinking culture |
| 16:10 | <jgraham> | Well, we have fruit too; Apples in the autum, strawberries for 2 weeks, raspberries for two weeks and blueberries for a while |
| 16:10 | <Velmont> | Yes, California > Norway there I guess ;-) |
| 16:10 | <jgraham> | It doesn't seem to be enough to have a fruit-based drinking culture |
| 16:10 | <Velmont> | Yes. Strawberries are very good though. -- Much better than the cheapo non-tasting stuff we get from spain, turkey etc. |
| 16:10 | <jgraham> | Indeed, soft fruits like cold climates |
| 16:11 | <Velmont> | Yes. Strawberries are very good though. -- Much better than the cheapo non-tasting stuff we get from spain, turkey etc. |
| 16:11 | <jgraham> | Indeed, soft fruits like cold climates |
| 16:11 | <jgraham> | Also, the varieties that last long enough to be transported are not the ones that taste good |
| 16:11 | <jgraham> | Also, the varieties that last long enough to be transported are not the ones that taste good |
| 16:11 | <Velmont> | :-) -- I'm SO looking forward to summer. Has been so hot in Oslo last days, - early spring I hope. |
| 16:12 | <Velmont> | :-) -- I'm SO looking forward to summer. Has been so hot in Oslo last days, - early spring I hope. |
| 16:12 | <jgraham> | You mean as much as +10? |
| 16:12 | <jgraham> | :) |
| 16:12 | <jgraham> | You mean as much as +10? |
| 16:12 | <jgraham> | :) |
| 16:12 | <jgraham> | (I think it reached +12 here which is crazy-warm for March) |
| 16:13 | <jgraham> | (I think it reached +12 here which is crazy-warm for March) |
| 16:13 | <Velmont> | jgraham: +17 in shadows on monday, used 1h lunch just sitting out in the sun. Niiice. -- Has been really sunny every day. --- BTW, that's actually the highest ever recorded in Oslo so early. |
| 16:13 | <Velmont> | jgraham: +17 in shadows on monday, used 1h lunch just sitting out in the sun. Niiice. -- Has been really sunny every day. --- BTW, that's actually the highest ever recorded in Oslo so early. |
| 16:25 | <jgraham> | +17? Crazy times |
| 16:25 | <jgraham> | +17? Crazy times |
| 16:31 | <bga> | http://pastebin.com/NKbnh8q8 |
| 16:32 | <bga> | http://pastebin.com/NKbnh8q8 |
| 16:42 | <Velmont> | Wat. Seems silly. |
| 16:51 | Philip` | wonders if they're aware that the IP addresses don't each correspond to a single server, they're pools of many servers spread around the world |
| 16:52 | Philip` | wonders if they're aware that the IP addresses don't each correspond to a single server, they're pools of many servers spread around the world |
| 16:53 | <Velmont> | Would think so, as it is very common knowlegde. |
| 16:53 | <StoneCypher> | assuming sophistication of an ill organized mob of script kiddies? |
| 16:53 | <Velmont> | Would think so, as it is very common knowlegde. |
| 16:53 | <StoneCypher> | i wouldn't. |
| 16:53 | <StoneCypher> | assuming sophistication of an ill organized mob of script kiddies? |
| 16:53 | <StoneCypher> | i wouldn't. |
| 17:39 | <annevk> | ugh |
| 17:40 | <annevk> | ugh |
| 17:40 | <annevk> | shift_jis to euc-jp is one ugly algorithm |
| 17:40 | <annevk> | and not even properly explained |
| 17:40 | <annevk> | it works |
| 17:40 | <annevk> | and not even properly explained |
| 17:40 | <annevk> | it works |
| 17:40 | <annevk> | the CJKV book just explains the C code |
| 17:40 | <annevk> | not the logic |
| 17:40 | <annevk> | lame |
| 17:41 | <annevk> | the CJKV book just explains the C code |
| 17:41 | <annevk> | not the logic |
| 17:41 | <annevk> | lame |
| 17:41 | <annevk> | i guess i'll just copy and paste to English |
| 17:41 | <annevk> | i guess i'll just copy and paste to English |
| 18:09 | <TabAtkins_> | annevk: re: the bug, presumably you're talking just about Selectors-in-JS, not the existing element() feature? |
| 18:10 | <TabAtkins_> | annevk: re: the bug, presumably you're talking just about Selectors-in-JS, not the existing element() feature? |
| 18:12 | <annevk> | if select() takes an arbitrary Selector that seems kind of weird too |
| 18:13 | <annevk> | if select() takes an arbitrary Selector that seems kind of weird too |
| 18:13 | <annevk> | I think it's better if you keep in-tree and out-of-tree as separate concepts |
| 18:13 | <TabAtkins_> | When that happens, the alternate behavior will only trigger for a single id selector. |
| 18:13 | <annevk> | I think it's better if you keep in-tree and out-of-tree as separate concepts |
| 18:13 | <TabAtkins_> | When that happens, the alternate behavior will only trigger for a single id selector. |
| 18:13 | <annevk> | and especially keep Selectors only matching in-tree |
| 18:14 | <annevk> | and especially keep Selectors only matching in-tree |
| 18:15 | <TabAtkins_> | I disagree, and would like to keep the feature as it's currently written. (It's awkward to do so, since bare idents look like tagname selectors...) |
| 18:15 | <TabAtkins_> | But I'm fine if the answer is "no, it shouldn't have any relevance to DOM". |
| 18:15 | <TabAtkins_> | I disagree, and would like to keep the feature as it's currently written. (It's awkward to do so, since bare idents look like tagname selectors...) |
| 18:15 | <TabAtkins_> | But I'm fine if the answer is "no, it shouldn't have any relevance to DOM". |
| 18:20 | <annevk> | modifying Selectors to match out-of-tree elements sounds very much like the wrong approach |
| 18:20 | <annevk> | modifying Selectors to match out-of-tree elements sounds very much like the wrong approach |
| 18:20 | <TabAtkins_> | Shrug. It seems useful here, and it's what Mozilla is already doing. |
| 18:20 | <annevk> | I'm not sure if that is what's going on here though as I haven't really read the element() proposal |
| 18:21 | <TabAtkins_> | Shrug. It seems useful here, and it's what Mozilla is already doing. |
| 18:21 | <annevk> | I'm not sure if that is what's going on here though as I haven't really read the element() proposal |
| 18:21 | <annevk> | that's not a very compelling argument to break a Selector invariant |
| 18:21 | <TabAtkins_> | So, short summary: |
| 18:21 | <annevk> | that's not a very compelling argument to break a Selector invariant |
| 18:21 | <TabAtkins_> | So, short summary: |
| 18:21 | <TabAtkins_> | element() takes an id selector, and represents an image that looks like the referenced element. |
| 18:21 | <annevk> | next you're going to suggest we should let them match Text nodes :) |
| 18:21 | jwalden | wants support for selectors that match comment nodes |
| 18:22 | <TabAtkins_> | element() takes an id selector, and represents an image that looks like the referenced element. |
| 18:22 | <annevk> | next you're going to suggest we should let them match Text nodes :) |
| 18:22 | jwalden | wants support for selectors that match comment nodes |
| 18:22 | <TabAtkins_> | Right now we phrase the out-of-doc thing as something that host languages can define. |
| 18:22 | <TabAtkins_> | But we may just make it explicit and put it into CSSOM or something. |
| 18:22 | <TabAtkins_> | Right now we phrase the out-of-doc thing as something that host languages can define. |
| 18:22 | <TabAtkins_> | But we may just make it explicit and put it into CSSOM or something. |
| 18:24 | <annevk> | it's very weird to have IDs matched outside the tree |
| 18:24 | <annevk> | it's very weird to have IDs matched outside the tree |
| 18:24 | <annevk> | there's no such feature currently |
| 18:24 | <Ms2ger> | element.getElementById? |
| 18:24 | <annevk> | Ms2ger: I thought that only matched in the tree |
| 18:25 | <annevk> | there's no such feature currently |
| 18:25 | <Ms2ger> | element.getElementById? |
| 18:25 | <annevk> | Ms2ger: I thought that only matched in the tree |
| 18:25 | <annevk> | it does |
| 18:25 | <annevk> | it does |
| 18:25 | <Ms2ger> | Oh |
| 18:25 | <Ms2ger> | In the subtree rooted at the element, you mean |
| 18:26 | <Ms2ger> | Oh |
| 18:26 | <Ms2ger> | In the subtree rooted at the element, you mean |
| 18:26 | <annevk> | I mean it doesn't match e=document.createElement("test");e.id='x' |
| 18:26 | <Ms2ger> | Yeah |
| 18:27 | <annevk> | I mean it doesn't match e=document.createElement("test");e.id='x' |
| 18:27 | <Ms2ger> | Yeah |
| 18:27 | <TabAtkins_> | Strictly, element() *doesn't* match ids outside the tree. |
| 18:27 | <Ms2ger> | I meant that it does match elements that aren't in a document |
| 18:27 | <Ms2ger> | (On which the spec was wrong previously) |
| 18:27 | <TabAtkins_> | Strictly, element() *doesn't* match ids outside the tree. |
| 18:27 | <Ms2ger> | I meant that it does match elements that aren't in a document |
| 18:27 | <Ms2ger> | (On which the spec was wrong previously) |
| 18:27 | <TabAtkins_> | However, it an id selector didn't match an element, it instead consults the map. |
| 18:27 | <TabAtkins_> | Which can contain in-document or out-of-document elements. |
| 18:28 | <TabAtkins_> | However, it an id selector didn't match an element, it instead consults the map. |
| 18:28 | <TabAtkins_> | Which can contain in-document or out-of-document elements. |
| 18:38 | <annevk> | Ms2ger: oh |
| 18:38 | <annevk> | Ms2ger: oh |
| 18:38 | <annevk> | TabAtkins_: I think it would be better to have a special look-in-map thing than this fallback magic |
| 18:38 | <annevk> | TabAtkins_: e.g. have element() for in-document and element-map() for this |
| 18:39 | <annevk> | TabAtkins_: I think it would be better to have a special look-in-map thing than this fallback magic |
| 18:39 | <annevk> | TabAtkins_: e.g. have element() for in-document and element-map() for this |
| 18:59 | <TabAtkins_> | annevk: That seems silly to me. |
| 18:59 | <TabAtkins_> | annevk: That seems silly to me. |
| 19:08 | <annevk> | why? |
| 19:08 | <annevk> | why? |
| 19:09 | <Hixie> | i have to say i do find it weird to have the #id mechanism match things by something other than the element's one true ID |
| 19:10 | <Hixie> | i have to say i do find it weird to have the #id mechanism match things by something other than the element's one true ID |
| 19:10 | <Hixie> | especially so soon after we've gone to the effort of erradicating all possible ways of having more than one ID |
| 19:10 | <Hixie> | especially so soon after we've gone to the effort of erradicating all possible ways of having more than one ID |
| 19:10 | <annevk> | oh yeah, if there's a custom identifier it seems even more wrong to use Selectors |
| 19:11 | <annevk> | oh yeah, if there's a custom identifier it seems even more wrong to use Selectors |
| 19:11 | <TabAtkins_> | Shrug. |
| 19:11 | <TabAtkins_> | Shrug. |
| 19:12 | <rniwa> | annevk, Ms2ger: regions spec apparently have flow change event or whatever |
| 19:12 | <rniwa> | that fires after flow changes :( |
| 19:13 | <rniwa> | annevk, Ms2ger: regions spec apparently have flow change event or whatever |
| 19:13 | <rniwa> | that fires after flow changes :( |
| 19:13 | <Ms2ger> | I sure hope nobody implements the regions cssom |
| 19:13 | <Hixie> | events from layout? lordy |
| 19:13 | <rniwa> | Ms2ger: webkit is doing that :( |
| 19:13 | <Ms2ger> | I sure hope nobody implements the regions cssom |
| 19:13 | <Hixie> | events from layout? lordy |
| 19:13 | <rniwa> | Ms2ger: webkit is doing that :( |
| 19:13 | <rniwa> | i'm trying to convince folks not to do it |
| 19:13 | <TabAtkins_> | We need some way to be able to refer to elements outside the DOM, it seems silly to add a second function with identical functionality just to do that type of referring, and leaning on the #id syntax appears to be the easiest way to merge the two functionalities together. |
| 19:13 | <TabAtkins_> | rniwa: Complain about it on www-style? |
| 19:14 | <rniwa> | i'm trying to convince folks not to do it |
| 19:14 | <TabAtkins_> | We need some way to be able to refer to elements outside the DOM, it seems silly to add a second function with identical functionality just to do that type of referring, and leaning on the #id syntax appears to be the easiest way to merge the two functionalities together. |
| 19:14 | <TabAtkins_> | rniwa: Complain about it on www-style? |
| 19:14 | <rniwa> | TabAtkins_: i'm kicked out of www-style for some random mail deamon issue |
| 19:14 | <rniwa> | TabAtkins_: i'm kicked out of www-style for some random mail deamon issue |
| 19:14 | <TabAtkins_> | rniwa: Ah, that sucks. |
| 19:14 | <Ms2ger> | It seems like there's more things wrong than right about that part of the spec... |
| 19:14 | <TabAtkins_> | Send the email to me and I'll forward it? |
| 19:15 | <TabAtkins_> | rniwa: Ah, that sucks. |
| 19:15 | <rniwa> | TabAtkins_: maybe. |
| 19:15 | <Ms2ger> | It seems like there's more things wrong than right about that part of the spec... |
| 19:15 | <TabAtkins_> | Send the email to me and I'll forward it? |
| 19:15 | <rniwa> | TabAtkins_: maybe. |
| 19:15 | <rniwa> | TabAtkins_: i'm hoping that people who are more familiar with the matter can comment on it |
| 19:15 | <annevk> | it's not identical functionality if you need a CSSElementMap etc. |
| 19:15 | <rniwa> | TabAtkins_: i'm hoping that people who are more familiar with the matter can comment on it |
| 19:15 | <annevk> | it's not identical functionality if you need a CSSElementMap etc. |
| 19:15 | <annevk> | it's very much a completely separate thing |
| 19:16 | <annevk> | it's very much a completely separate thing |
| 19:16 | <Hixie> | yeah if we're adding a whole bunch of api surface anyway, what's a new selector |
| 19:16 | <TabAtkins_> | rniwa: I'm not familiar with the matter, so shrug. |
| 19:16 | <TabAtkins_> | rniwa: I'm not familiar with the matter, so shrug. |
| 19:16 | <TabAtkins_> | Ms2ger: Details? I've been fixing odd corners as they come up, but there isn't much. |
| 19:17 | <TabAtkins_> | Ms2ger: Details? I've been fixing odd corners as they come up, but there isn't much. |
| 19:23 | <TabAtkins_> | Argh, I can't get my fingers to stop typing "cvs commit" when I mean "hg commit". |
| 19:23 | <TabAtkins_> | Argh, I can't get my fingers to stop typing "cvs commit" when I mean "hg commit". |
| 19:23 | <Ms2ger> | alias cvs hg |
| 19:23 | <TabAtkins_> | I was thinking about that. |
| 19:24 | <Ms2ger> | alias cvs hg |
| 19:24 | <TabAtkins_> | I was thinking about that. |
| 19:24 | <annevk> | Ms2ger: afaict http://mxr.mozilla.org/mozilla-central/source/intl/uconv/ucvja/nsJapaneseToUnicode.cpp#205 is dead code |
| 19:25 | <annevk> | Ms2ger: afaict http://mxr.mozilla.org/mozilla-central/source/intl/uconv/ucvja/nsJapaneseToUnicode.cpp#205 is dead code |
| 19:25 | <annevk> | Ms2ger: same goes for some stuff in japanese.map; also, http://mxr.mozilla.org/mozilla-central/source/intl/uconv/ucvja/japanese.map#80 0x80 is not handled there |
| 19:25 | <annevk> | Ms2ger: same goes for some stuff in japanese.map; also, http://mxr.mozilla.org/mozilla-central/source/intl/uconv/ucvja/japanese.map#80 0x80 is not handled there |
| 19:26 | <Ms2ger> | Looks like it's called from the old HTML parser |
| 19:26 | <Ms2ger> | Not sure if it's dead yet |
| 19:26 | <Ms2ger> | Looks like it's called from the old HTML parser |
| 19:26 | <Ms2ger> | Not sure if it's dead yet |
| 19:28 | <annevk> | o_O |
| 19:28 | <annevk> | that's some weird stuff |
| 19:28 | <Ms2ger> | The old HTML parser? |
| 19:28 | <Ms2ger> | Yes |
| 19:28 | <annevk> | o_O |
| 19:28 | <annevk> | that's some weird stuff |
| 19:28 | <Ms2ger> | The old HTML parser? |
| 19:28 | <Ms2ger> | Yes |
| 19:32 | <annevk> | TabAtkins_: if you're not interested in feedback you should not edit specs |
| 19:32 | <annevk> | shrug away |
| 19:32 | <annevk> | TabAtkins_: if you're not interested in feedback you should not edit specs |
| 19:32 | <annevk> | shrug away |
| 19:32 | <Ms2ger> | Uh? |
| 19:32 | <TabAtkins_> | annevk: Uh, what. |
| 19:32 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=16169#c5 |
| 19:32 | <TabAtkins_> | Or let me put that more appropriately: |
| 19:32 | <TabAtkins_> | lolwut |
| 19:32 | <TabAtkins_> | I rejected your feedback because I disagree. |
| 19:33 | <Ms2ger> | Uh? |
| 19:33 | <TabAtkins_> | annevk: Uh, what. |
| 19:33 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=16169#c5 |
| 19:33 | <TabAtkins_> | Or let me put that more appropriately: |
| 19:33 | <TabAtkins_> | lolwut |
| 19:33 | <TabAtkins_> | I rejected your feedback because I disagree. |
| 19:33 | <TabAtkins_> | That's a perfectly normal thing to do. |
| 19:33 | <TabAtkins_> | That's a perfectly normal thing to do. |
| 19:33 | <TabAtkins_> | As is attempting to focus a bug on the question at hand rather than a related tangent. |
| 19:33 | <annevk> | not if there's no argument |
| 19:34 | <TabAtkins_> | As is attempting to focus a bug on the question at hand rather than a related tangent. |
| 19:34 | <annevk> | not if there's no argument |
| 19:34 | <TabAtkins_> | The argument was "I think it's fine, and it matches an existing implementation." Since your argument was "I think it's better this way", that seems about right. |
| 19:34 | <TabAtkins_> | The argument was "I think it's fine, and it matches an existing implementation." Since your argument was "I think it's better this way", that seems about right. |
| 19:35 | <TabAtkins_> | There's nothing technically wrong with the feature as specced; you disagree with it from an aesthetic perspective. That's not unimportant, but it does mean that it's hard to be "right". |
| 19:36 | <TabAtkins_> | There's nothing technically wrong with the feature as specced; you disagree with it from an aesthetic perspective. That's not unimportant, but it does mean that it's hard to be "right". |
| 19:37 | <annevk> | it breaks an invariant of selectors |
| 19:37 | <annevk> | that's not aesthetics |
| 19:37 | <annevk> | it breaks an invariant of selectors |
| 19:37 | <annevk> | that's not aesthetics |
| 19:38 | <TabAtkins_> | But it doesn't. |
| 19:38 | <TabAtkins_> | But it doesn't. |
| 19:38 | hober | agrees with annevk |
| 19:38 | <TabAtkins_> | Because there isn't any such invariant. |
| 19:39 | hober | agrees with annevk |
| 19:39 | <TabAtkins_> | Because there isn't any such invariant. |
| 19:41 | <AryehGregor> | If we're talking about #foo meaning anything other than "an element in the document with id="foo"", I also agree with annevk. |
| 19:41 | <AryehGregor> | If we're talking about #foo meaning anything other than "an element in the document with id="foo"", I also agree with annevk. |
| 20:25 | <jgraham> | +1 on #id matching out of document being all kinds of wrong |
| 20:26 | <jgraham> | +1 on #id matching out of document being all kinds of wrong |
| 20:28 | <smaug____> | ID matching out of document sounds broken |
| 20:28 | <smaug____> | ID matching out of document sounds broken |
| 20:31 | <TabAtkins_> | Sigh. I strongly suspect the context is lost here. |
| 20:32 | <TabAtkins_> | Sigh. I strongly suspect the context is lost here. |
| 20:32 | <TabAtkins_> | In particular, I could just define that, for the purpose of selector matching, elements in the CSSElementMap are "in document" but are root elements following the normal document root. |
| 20:33 | <TabAtkins_> | In particular, I could just define that, for the purpose of selector matching, elements in the CSSElementMap are "in document" but are root elements following the normal document root. |
| 20:33 | <TabAtkins_> | This is *not* about, say, creating an element with an id from script, not inserting it into the document, and then expecting document.getElementById('foo') to return it. |
| 20:33 | <rniwa> | AryehGregor, annevk: https://bugs.webkit.org/show_bug.cgi?id=81141 |
| 20:34 | <TabAtkins_> | This is *not* about, say, creating an element with an id from script, not inserting it into the document, and then expecting document.getElementById('foo') to return it. |
| 20:34 | <rniwa> | AryehGregor, annevk: https://bugs.webkit.org/show_bug.cgi?id=81141 |
| 20:34 | <TabAtkins_> | (I wouldn't go to that trouble, because there's no need to, but whatever.) |
| 20:34 | <rniwa> | fixing a mutation event bug resulted in a regression :( |
| 20:34 | <rniwa> | i.e. we can't implement mutation events as spec'ed. if we did, we break the web |
| 20:34 | <rniwa> | fixing a mutation event bug resulted in a regression :( |
| 20:34 | <rniwa> | i.e. we can't implement mutation events as spec'ed. if we did, we break the web |
| 20:34 | <rniwa> | epic fail... |
| 20:34 | <Hixie> | TabAtkins_: fwiw my problem isn't with it matching things out of document, i think that selectors matching things out of document is fine, that the scope should be up to whoever is defining the selector context |
| 20:35 | <rniwa> | epic fail... |
| 20:35 | <Hixie> | TabAtkins_: fwiw my problem isn't with it matching things out of document, i think that selectors matching things out of document is fine, that the scope should be up to whoever is defining the selector context |
| 20:35 | <Hixie> | TabAtkins_: my problem is with ID selectors matching things that aren't IDs :-) |
| 20:35 | <jgraham> | TabAtkins_: You could define that, but I still think it is weird and wrong |
| 20:35 | AryehGregor | agrees with Hixie |
| 20:35 | <Hixie> | TabAtkins_: my problem is with ID selectors matching things that aren't IDs :-) |
| 20:35 | <jgraham> | TabAtkins_: You could define that, but I still think it is weird and wrong |
| 20:35 | AryehGregor | agrees with Hixie |
| 20:36 | <TabAtkins_> | Hixie: What's wrong with defining more than just the @id attribute to provide an ID for an element? |
| 20:36 | <TabAtkins_> | Hixie: What's wrong with defining more than just the @id attribute to provide an ID for an element? |
| 20:36 | <Ms2ger> | We just killed that |
| 20:36 | <Hixie> | TabAtkins_: we just spent a bunch of effort erradicating every last thing that allowed multiple IDs per element (ask anne and Ms2ger for why) |
| 20:36 | <Ms2ger> | Ask anne :) |
| 20:36 | <TabAtkins_> | I'd like some context, yeah. |
| 20:37 | <Ms2ger> | We just killed that |
| 20:37 | <Hixie> | TabAtkins_: we just spent a bunch of effort erradicating every last thing that allowed multiple IDs per element (ask anne and Ms2ger for why) |
| 20:37 | <Ms2ger> | Ask anne :) |
| 20:37 | <TabAtkins_> | I'd like some context, yeah. |
| 20:39 | jgraham | also doesn't like the fact that the "same" selector matches different things according to context |
| 20:39 | jgraham | also doesn't like the fact that the "same" selector matches different things according to context |
| 20:43 | <othermaciej> | TabAtkins_: I think it would be super confusing for the id selector to match by something that's not visible to getElementById() |
| 20:43 | <othermaciej> | TabAtkins_: I think it would be super confusing for the id selector to match by something that's not visible to getElementById() |
| 20:43 | gsnedders | agrees with othermaciej |
| 20:43 | <annevk> | TabAtkins_: e.g. there was xml:id, DTD IDs, id="", etc. |
| 20:44 | gsnedders | agrees with othermaciej |
| 20:44 | <annevk> | TabAtkins_: e.g. there was xml:id, DTD IDs, id="", etc. |
| 20:44 | <annevk> | TabAtkins_: now there's just id="" |
| 20:44 | <TabAtkins_> | annevk: Those all affected the DOM (or at least, were supposed to), right? |
| 20:44 | <TabAtkins_> | annevk: Those all affected the DOM (or at least, were supposed to), right? |
| 20:44 | <annevk> | they were all ways to give an element multiple IDs |
| 20:45 | <annevk> | they were all ways to give an element multiple IDs |
| 20:45 | <TabAtkins_> | othermaciej, jgraham : I welcome suggestions on how to fit it into the syntax otherwise. |
| 20:46 | <TabAtkins_> | othermaciej, jgraham : I welcome suggestions on how to fit it into the syntax otherwise. |
| 20:46 | <TabAtkins_> | Note our current constraints: We expect element() to be extended in the future to accept arbitrary selectors (not just id selectors, as it does currently). We also expect it to be extended to accept urls as <string>s. |
| 20:46 | <TabAtkins_> | Note our current constraints: We expect element() to be extended in the future to accept arbitrary selectors (not just id selectors, as it does currently). We also expect it to be extended to accept urls as <string>s. |
| 20:46 | <annevk> | rniwa: breaking mutation events works for me |
| 20:47 | <annevk> | rniwa: breaking mutation events works for me |
| 20:47 | <othermaciej> | TabAtkins_: one possibility is to have a list, rather than a map, of out-of-document elements whose actual id attribute will be visible to id selectors, getElemetById(), and all other id lookup mechanisms |
| 20:47 | <annevk> | rniwa: the plan is to nuke them completely |
| 20:47 | <rniwa> | annevk: ok, thanks |
| 20:47 | <othermaciej> | TabAtkins_: one possibility is to have a list, rather than a map, of out-of-document elements whose actual id attribute will be visible to id selectors, getElemetById(), and all other id lookup mechanisms |
| 20:47 | <annevk> | rniwa: the plan is to nuke them completely |
| 20:47 | <rniwa> | annevk: ok, thanks |
| 20:47 | <annevk> | rniwa: the more they become broken, the easier it is to convince people to use mutation observers... |
| 20:47 | <othermaciej> | TabAtkins_: I'm not sure offhand if that is a good idea, but at least it avoids multiple ids and selector vs. DOM divergence on what is an id |
| 20:48 | <annevk> | rniwa: the more they become broken, the easier it is to convince people to use mutation observers... |
| 20:48 | <othermaciej> | TabAtkins_: I'm not sure offhand if that is a good idea, but at least it avoids multiple ids and selector vs. DOM divergence on what is an id |
| 20:49 | <TabAtkins_> | othermaciej: Interesting. |
| 20:50 | <TabAtkins_> | othermaciej: Interesting. |
| 20:53 | <Hixie> | that would also let us kill the csselementmap |
| 20:53 | <Hixie> | i'm always in favour of removing features without hurting use cases :-) |
| 20:54 | <Hixie> | that would also let us kill the csselementmap |
| 20:54 | <Hixie> | i'm always in favour of removing features without hurting use cases :-) |
| 20:54 | <TabAtkins_> | Well, it would kill it by replacing it with something else. |
| 20:54 | <Hixie> | can i just say that it is mildly confusing that what WebIDL calls sequences (sequence<foo>) is an Array and what it calls arrays (foo[]) is not? |
| 20:55 | <TabAtkins_> | Well, it would kill it by replacing it with something else. |
| 20:55 | <Hixie> | can i just say that it is mildly confusing that what WebIDL calls sequences (sequence<foo>) is an Array and what it calls arrays (foo[]) is not? |
| 20:55 | <TabAtkins_> | With the "something else" being roughly equally complicated. |
| 20:55 | <TabAtkins_> | With the "something else" being roughly equally complicated. |
| 20:55 | <Hixie> | TabAtkins_: i guess |
| 20:55 | <Hixie> | TabAtkins_: i guess |
| 20:55 | <TabAtkins_> | The use-case I'm trying to hit is really important and needs *something* along these lines, no matter the syntax. |
| 20:55 | <Hixie> | TabAtkins_: makes your life easier though, since it would be css-independent |
| 20:55 | <Hixie> | makes my life easier too |
| 20:55 | <Hixie> | it would be anne's problem :-D |
| 20:56 | <TabAtkins_> | The use-case I'm trying to hit is really important and needs *something* along these lines, no matter the syntax. |
| 20:56 | <Hixie> | TabAtkins_: makes your life easier though, since it would be css-independent |
| 20:56 | <Hixie> | makes my life easier too |
| 20:56 | <Hixie> | it would be anne's problem :-D |
| 20:56 | <annevk> | Hixie: I think sequence is not necessarily an array |
| 20:56 | <annevk> | Hixie: I think sequence is not necessarily an array |
| 20:56 | <Hixie> | annevk: "IDL sequence<T> values are represented by ECMAScript Array values" |
| 20:56 | <TabAtkins_> | annevk doesn't think there's a use-case for it in JS (and I agree). The only benefit of making this visible to the rest of DOM is to make sure that element() selectors match the same elements that JS selectors do. |
| 20:57 | <Hixie> | annevk: "IDL sequence<T> values are represented by ECMAScript Array values" |
| 20:57 | <TabAtkins_> | annevk doesn't think there's a use-case for it in JS (and I agree). The only benefit of making this visible to the rest of DOM is to make sure that element() selectors match the same elements that JS selectors do. |
| 20:57 | <annevk> | Hixie: oh I thought sequence stuff was for passing in arguments and could be anything array-like |
| 20:57 | <annevk> | hmm |
| 20:57 | <annevk> | Hixie: oh I thought sequence stuff was for passing in arguments and could be anything array-like |
| 20:57 | <annevk> | hmm |
| 20:57 | <annevk> | I keep getting confused by Web IDL |
| 20:57 | <Hixie> | annevk: i'm talking about return values, might be different for receiving values |
| 20:57 | <annevk> | not good :/ |
| 20:58 | <annevk> | I keep getting confused by Web IDL |
| 20:58 | <Hixie> | annevk: i'm talking about return values, might be different for receiving values |
| 20:58 | <annevk> | I didn't know it could be a return value |
| 20:58 | <annevk> | not good :/ |
| 20:58 | <annevk> | I didn't know it could be a return value |
| 20:59 | <annevk> | so sequences can only be returned from methods per http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence |
| 20:59 | <annevk> | so sequences can only be returned from methods per http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence |
| 20:59 | <Hixie> | right |
| 21:00 | <Hixie> | right |
| 21:07 | <othermaciej> | Hixie: I think the [] stuff should possibly be just made a synonym for sequence<>, if there's nothing actively using it |
| 21:07 | <othermaciej> | I don't think the [] fake arrays are very useful |
| 21:07 | <Ms2ger> | But live stuff |
| 21:08 | <othermaciej> | Hixie: I think the [] stuff should possibly be just made a synonym for sequence<>, if there's nothing actively using it |
| 21:08 | <othermaciej> | I don't think the [] fake arrays are very useful |
| 21:08 | <Ms2ger> | But live stuff |
| 21:08 | <annevk> | othermaciej: actual JS Arrays can be mutated |
| 21:08 | <annevk> | othermaciej: actual JS Arrays can be mutated |
| 21:08 | <Hixie> | yeah i use the [] thing |
| 21:08 | <annevk> | othermaciej: which is problematic |
| 21:09 | <Hixie> | yeah i use the [] thing |
| 21:09 | <annevk> | othermaciej: which is problematic |
| 21:09 | <annevk> | othermaciej: I do agree it would be nice if it was all somewhat simpler though, but I don't know enough about all the constraints |
| 21:10 | <annevk> | othermaciej: I do agree it would be nice if it was all somewhat simpler though, but I don't know enough about all the constraints |
| 21:12 | <jgraham> | Seems like the nice solution would be to invent a time machine and add immutable arrays to js about 15 years ago |
| 21:13 | <jgraham> | Seems like the nice solution would be to invent a time machine and add immutable arrays to js about 15 years ago |
| 21:13 | <jgraham> | Dunno how much it would help to do it now (except that immutable data structures are pretty nice in some situations ofc) |
| 21:13 | <jgraham> | Dunno how much it would help to do it now (except that immutable data structures are pretty nice in some situations ofc) |
| 21:13 | <Ms2ger> | Well, just immutable by script |
| 21:14 | <Ms2ger> | Well, just immutable by script |
| 21:14 | <Hixie> | if you invent a time machine, i have some higher priorities for you |
| 21:14 | <Hixie> | if you invent a time machine, i have some higher priorities for you |
| 21:14 | <Hixie> | even just within the scope of js! |
| 21:14 | <Ms2ger> | longdesc? |
| 21:14 | <Philip`> | If you invent a time machine you don't need to bother with priorities, you can just do everything simultaneously |
| 21:14 | <Hixie> | Philip`: depends how it works! |
| 21:15 | <Hixie> | even just within the scope of js! |
| 21:15 | <Ms2ger> | longdesc? |
| 21:15 | <Philip`> | If you invent a time machine you don't need to bother with priorities, you can just do everything simultaneously |
| 21:15 | <Hixie> | Philip`: depends how it works! |
| 21:15 | <Ms2ger> | But as it's unlikely we'll invent any kind, please go ahead and fix HTML bugs :) |
| 21:16 | <Ms2ger> | But as it's unlikely we'll invent any kind, please go ahead and fix HTML bugs :) |
| 21:19 | <annevk> | if we do, make everything utf-8 only kthxbai |
| 21:20 | <annevk> | if we do, make everything utf-8 only kthxbai |
| 21:38 | <annevk> | http://www.ted.com/talks/rob_reid_the_8_billion_ipod.html |
| 21:39 | <annevk> | http://www.ted.com/talks/rob_reid_the_8_billion_ipod.html |
| 21:40 | <bga> | http://www.opencalais.com/about |
| 21:41 | <bga> | http://www.opencalais.com/about |
| 21:41 | <Ms2ger> | http://www.catsguru.com/wp-content/uploads/2010/09/new-kitten.jpg |
| 21:42 | <Ms2ger> | http://www.catsguru.com/wp-content/uploads/2010/09/new-kitten.jpg |
| 21:43 | gsnedders | definitely prefers Ms2ger's link |
| 21:43 | gsnedders | definitely prefers Ms2ger's link |
| 21:46 | <bga> | photoshop |
| 21:47 | <bga> | photoshop |
| 21:54 | <jgraham> | Open Calais? Presumably that's when there isn't a strike on in France |
| 21:54 | <jgraham> | Open Calais? Presumably that's when there isn't a strike on in France |
| 21:54 | <Ms2ger> | One day a year? |
| 21:54 | <jgraham> | Oh, do they have a special holiday? |
| 21:55 | <Ms2ger> | One day a year? |
| 21:55 | <jgraham> | Oh, do they have a special holiday? |
| 22:00 | <Hixie> | ok. let's talk dash styles. |
| 22:00 | <Hixie> | it's an array of lengths. |
| 22:00 | <Ms2ger> | Let's not :) |
| 22:00 | <Hixie> | ok. let's talk dash styles. |
| 22:00 | <Hixie> | it's an array of lengths. |
| 22:00 | <Ms2ger> | Let's not :) |
| 22:00 | <Hixie> | odd lengths give the distance "on" and even ones the distance "off" |
| 22:00 | <Hixie> | odd-length arrays are doubles so you get the effect then the mirror |
| 22:00 | <Hixie> | e.g. 1,2,3 becomes -__---_--___ |
| 22:01 | <Hixie> | odd lengths give the distance "on" and even ones the distance "off" |
| 22:01 | <Hixie> | odd-length arrays are doubles so you get the effect then the mirror |
| 22:01 | <Hixie> | e.g. 1,2,3 becomes -__---_--___ |
| 22:01 | <Hixie> | so. zeroes. |
| 22:01 | <Hixie> | we strip zero-length segments, so it's a bit like they weren't there |
| 22:01 | <Hixie> | so. zeroes. |
| 22:01 | <Hixie> | we strip zero-length segments, so it's a bit like they weren't there |
| 22:01 | <Hixie> | 1,0,1,2 is like 2,2 |
| 22:01 | <Ms2ger> | Is it? |
| 22:02 | <Hixie> | 1,0,1,2 is like 2,2 |
| 22:02 | <Ms2ger> | Is it? |
| 22:02 | <Ms2ger> | Not like 1,1,2? |
| 22:02 | <Ms2ger> | Not like 1,1,2? |
| 22:02 | <Hixie> | 1,0,1,2 becomes "- (zero-length off) - __" i.e. "--__" i.e. 2,2 |
| 22:03 | <Hixie> | 1,0,1,2 becomes "- (zero-length off) - __" i.e. "--__" i.e. 2,2 |
| 22:03 | <Ms2ger> | Doesn't look like stripping them, then :) |
| 22:03 | <Ms2ger> | Doesn't look like stripping them, then :) |
| 22:03 | <Hixie> | zero-length line segments, not zero entries in the array, sorry |
| 22:03 | <zewt> | collapsed/coalesced/whatever |
| 22:03 | <Hixie> | i don't think we should throw an exception for zeros, since you could end up with them when you're just making a gap smaller and smaller |
| 22:03 | <Ms2ger> | Go on :) |
| 22:04 | <Hixie> | zero-length line segments, not zero entries in the array, sorry |
| 22:04 | <Hixie> | so what happens to trailing zeroes? |
| 22:04 | <zewt> | collapsed/coalesced/whatever |
| 22:04 | <Hixie> | i don't think we should throw an exception for zeros, since you could end up with them when you're just making a gap smaller and smaller |
| 22:04 | <Ms2ger> | Go on :) |
| 22:04 | <Hixie> | so what happens to trailing zeroes? |
| 22:04 | <Hixie> | 1,0 => solid? or same as 1,1? |
| 22:04 | <Hixie> | 1,0 => solid? or same as 1,1? |
| 22:04 | <Hixie> | i'd say solid |
| 22:04 | <zewt> | 1,1 doesn't make sense |
| 22:04 | <zewt> | (from 1,0) |
| 22:04 | <Hixie> | ok |
| 22:04 | <Hixie> | so what does 0,1,0 become? |
| 22:05 | <Hixie> | i'd say solid |
| 22:05 | <zewt> | 1,1 doesn't make sense |
| 22:05 | <zewt> | (from 1,0) |
| 22:05 | <Hixie> | ok |
| 22:05 | <Hixie> | so what does 0,1,0 become? |
| 22:05 | <TabAtkins_> | Hixie: Yes, 1,0,1,2 shoudl basically look like 2,2. |
| 22:05 | <TabAtkins_> | Hixie: Yes, 1,0,1,2 shoudl basically look like 2,2. |
| 22:05 | <TabAtkins_> | 0,1,0 looks like no stroke at all. |
| 22:05 | <zewt> | what do odd-length sequences mean? |
| 22:05 | <TabAtkins_> | zewt: Repeat the sequence once. |
| 22:05 | <TabAtkins_> | zewt: So you get an even-length one. |
| 22:05 | <TabAtkins_> | 0,1,0 looks like no stroke at all. |
| 22:05 | <zewt> | what do odd-length sequences mean? |
| 22:05 | <TabAtkins_> | zewt: Repeat the sequence once. |
| 22:05 | <TabAtkins_> | zewt: So you get an even-length one. |
| 22:05 | <Ms2ger> | 1,1? |
| 22:05 | <zewt> | so repeat it before eliminating zeroes |
| 22:05 | <jgraham> | You don't eliminate zeros afaict |
| 22:05 | <TabAtkins_> | zewt: Yeah. You don't *actually* eliminate zeros. |
| 22:06 | <Ms2ger> | 1,1? |
| 22:06 | <zewt> | so repeat it before eliminating zeroes |
| 22:06 | <jgraham> | You don't eliminate zeros afaict |
| 22:06 | <TabAtkins_> | zewt: Yeah. You don't *actually* eliminate zeros. |
| 22:06 | Hixie | is planning on eliminating zeroes |
| 22:06 | <TabAtkins_> | But zero-length segments are treated like they're not there, and Hixie defines dashes by cutting up a segment into lots of little segments. |
| 22:06 | <zewt> | 0,1,0 -> 0,1,0,1,0,1 -> 0,2,0,1 -> 0,3 |
| 22:06 | <TabAtkins_> | Hixie: I suggest not doing something different from SVG. |
| 22:06 | Hixie | is planning on eliminating zeroes |
| 22:06 | <TabAtkins_> | But zero-length segments are treated like they're not there, and Hixie defines dashes by cutting up a segment into lots of little segments. |
| 22:06 | <zewt> | 0,1,0 -> 0,1,0,1,0,1 -> 0,2,0,1 -> 0,3 |
| 22:06 | <TabAtkins_> | Hixie: I suggest not doing something different from SVG. |
| 22:06 | <jgraham> | Hixie: Zeros seem to be entirely non magical? |
| 22:06 | <jgraham> | I mean they are just a segment of length 0 |
| 22:07 | <jgraham> | Hixie: Zeros seem to be entirely non magical? |
| 22:07 | <Hixie> | TabAtkins_: do they draw line caps between the segments in 1,0? |
| 22:07 | <jgraham> | I mean they are just a segment of length 0 |
| 22:07 | <Hixie> | TabAtkins_: do they draw line caps between the segments in 1,0? |
| 22:07 | <TabAtkins_> | Hixie: Let me check! |
| 22:07 | <TabAtkins_> | Hixie: Let me check! |
| 22:07 | <Hixie> | TabAtkins_: (are we sure svg drops zero-length path segments? so they can't do the "dash dot" effect with round dots?) |
| 22:07 | <TabAtkins_> | How do I trigger linecaps here? You mean like having a path with an M instruction happening in the middle of a segment? |
| 22:08 | <Hixie> | TabAtkins_: (are we sure svg drops zero-length path segments? so they can't do the "dash dot" effect with round dots?) |
| 22:08 | <TabAtkins_> | How do I trigger linecaps here? You mean like having a path with an M instruction happening in the middle of a segment? |
| 22:08 | <Hixie> | i dunno how svg does it |
| 22:08 | <Hixie> | in canvas, you get a line cap at the ends of each subpath |
| 22:08 | <Hixie> | depends on context.lineCap |
| 22:08 | <TabAtkins_> | Okay. |
| 22:08 | <Hixie> | or lineCaps |
| 22:08 | <Hixie> | i dunno how svg does it |
| 22:08 | <Hixie> | in canvas, you get a line cap at the ends of each subpath |
| 22:08 | <Hixie> | depends on context.lineCap |
| 22:08 | <TabAtkins_> | Okay. |
| 22:08 | <Hixie> | or lineCaps |
| 22:08 | <Hixie> | or something |
| 22:08 | <TabAtkins_> | Same deal, then. an M starts a new subpath. |
| 22:08 | <TabAtkins_> | Triggering linecaps. |
| 22:09 | <Hixie> | or something |
| 22:09 | <TabAtkins_> | Same deal, then. an M starts a new subpath. |
| 22:09 | <TabAtkins_> | Triggering linecaps. |
| 22:11 | <bga> | <picture> is just kind a old <img> w/ lowsrc ? |
| 22:12 | <bga> | <picture> is just kind a old <img> w/ lowsrc ? |
| 22:12 | <Hixie> | TabAtkins_: but do they ahve them between zero-width gaps in dashed lines? |
| 22:12 | <TabAtkins_> | Hixie: SVG drops 0s entirely: |
| 22:12 | <TabAtkins_> | So "1 0" doesn't trigger any linecaps. |
| 22:12 | <Hixie> | TabAtkins_: but do they ahve them between zero-width gaps in dashed lines? |
| 22:12 | <TabAtkins_> | Hixie: SVG drops 0s entirely: |
| 22:12 | <TabAtkins_> | So "1 0" doesn't trigger any linecaps. |
| 22:12 | <Hixie> | what does 0 1 do? |
| 22:12 | <TabAtkins_> | No path displayed at all. |
| 22:12 | <Hixie> | interesting |
| 22:13 | <Hixie> | what does 0 1 do? |
| 22:13 | <TabAtkins_> | No path displayed at all. |
| 22:13 | <Hixie> | interesting |
| 22:13 | <Hixie> | where is this defined? |
| 22:13 | <heycam|away> | TabAtkins_, what's the example again? |
| 22:13 | <TabAtkins_> | I'm running off of Chrome's SVG impl right now. ^_^& |
| 22:13 | <Hixie> | where is this defined? |
| 22:13 | <heycam|away> | TabAtkins_, what's the example again? |
| 22:13 | <TabAtkins_> | I'm running off of Chrome's SVG impl right now. ^_^& |
| 22:13 | <heycam> | "dropping 0s" doesn't sound right to me but I missed the exact context |
| 22:13 | <TabAtkins_> | heycam: <path d="M 10 10 h 100 M 10 20 h 100" stroke-dasharray="10 0" stroke="black" stroke-width="5" stroke-linecap="round" /> |
| 22:13 | <Hixie> | TabAtkins_: oh i thought you were checking the spec :-) |
| 22:14 | <heycam> | "dropping 0s" doesn't sound right to me but I missed the exact context |
| 22:14 | <TabAtkins_> | Let's see what the SVg spec actually says... |
| 22:14 | <TabAtkins_> | heycam: <path d="M 10 10 h 100 M 10 20 h 100" stroke-dasharray="10 0" stroke="black" stroke-width="5" stroke-linecap="round" /> |
| 22:14 | <Hixie> | TabAtkins_: oh i thought you were checking the spec :-) |
| 22:14 | <TabAtkins_> | Let's see what the SVg spec actually says... |
| 22:14 | <Hixie> | TabAtkins_: don't trust implementations on edge cases like this :-) |
| 22:14 | <heycam> | that should mean round dashes of length 10 which overlap each other, I think |
| 22:14 | <Hixie> | TabAtkins_: don't trust implementations on edge cases like this :-) |
| 22:14 | <heycam> | that should mean round dashes of length 10 which overlap each other, I think |
| 22:14 | <heycam> | overlap on the round bits |
| 22:14 | <TabAtkins_> | Hm, wait. |
| 22:14 | <TabAtkins_> | I may not be able to detect it with this case. |
| 22:14 | <TabAtkins_> | Need some opacity. |
| 22:14 | <Hixie> | or a corner |
| 22:14 | <Hixie> | corner is better |
| 22:15 | <heycam> | overlap on the round bits |
| 22:15 | <TabAtkins_> | Hm, wait. |
| 22:15 | <TabAtkins_> | I may not be able to detect it with this case. |
| 22:15 | <TabAtkins_> | Need some opacity. |
| 22:15 | <Hixie> | or a corner |
| 22:15 | <Hixie> | corner is better |
| 22:15 | <Hixie> | opacity doesn't necessarily work, depends how the stroke is defined |
| 22:15 | <Hixie> | and i don't know if svg is detailed enough about that |
| 22:15 | <TabAtkins_> | Ah, true. |
| 22:15 | <Hixie> | opacity doesn't necessarily work, depends how the stroke is defined |
| 22:15 | <Hixie> | and i don't know if svg is detailed enough about that |
| 22:15 | <TabAtkins_> | Ah, true. |
| 22:16 | <heycam> | if you make it stroke-dasharray="10 2" you can see the overlap |
| 22:16 | <heycam> | i.e. you can see where the round bits are nearly completely overlapping |
| 22:16 | <TabAtkins_> | Yeah, but that's easy. |
| 22:16 | <heycam> | if you make it stroke-dasharray="10 2" you can see the overlap |
| 22:16 | <heycam> | i.e. you can see where the round bits are nearly completely overlapping |
| 22:16 | <TabAtkins_> | Yeah, but that's easy. |
| 22:16 | <heycam> | what's the problem with the 0? |
| 22:16 | <TabAtkins_> | We need a way to detect the difference between "fully overlapping" and "no linecap at all". |
| 22:16 | <TabAtkins_> | I think Hixie's right that a corner would work. |
| 22:16 | <Hixie> | heycam: does svg say to cut the line at a zero-length dash, or does it let the line be solid? |
| 22:17 | <heycam> | what's the problem with the 0? |
| 22:17 | <TabAtkins_> | We need a way to detect the difference between "fully overlapping" and "no linecap at all". |
| 22:17 | <TabAtkins_> | I think Hixie's right that a corner would work. |
| 22:17 | <Hixie> | heycam: does svg say to cut the line at a zero-length dash, or does it let the line be solid? |
| 22:17 | <Hixie> | no line cap with a corner is another way of testing it |
| 22:17 | <Hixie> | since you'll have or not have a join |
| 22:17 | <Hixie> | no line cap with a corner is another way of testing it |
| 22:17 | <heycam> | it doesn't say to cut the dash if the cap overlaps it |
| 22:17 | <Hixie> | if the gap occurs right at the corner |
| 22:17 | <Hixie> | since you'll have or not have a join |
| 22:17 | <heycam> | it doesn't say to cut the dash if the cap overlaps it |
| 22:17 | <Hixie> | if the gap occurs right at the corner |
| 22:17 | <Hixie> | heycam: forget the cap |
| 22:17 | <heycam> | but I doubt it says anything that detailed |
| 22:17 | <heycam> | ok |
| 22:17 | <Hixie> | heycam: i the line dash pattern is 10 on, 0 off |
| 22:17 | <Hixie> | heycam: and you stroke a line of length 20 |
| 22:18 | <Hixie> | heycam: forget the cap |
| 22:18 | <heycam> | but I doubt it says anything that detailed |
| 22:18 | <heycam> | ok |
| 22:18 | <TabAtkins_> | Ok, Chrome at least *does* draw linecaps between segments separated by a 0 off segment. |
| 22:18 | <Hixie> | heycam: i the line dash pattern is 10 on, 0 off |
| 22:18 | <Hixie> | heycam: and you stroke a line of length 20 |
| 22:18 | <TabAtkins_> | Ok, Chrome at least *does* draw linecaps between segments separated by a 0 off segment. |
| 22:18 | <heycam> | Hixie, yes... |
| 22:18 | <Hixie> | heycam: and your line has a corner at distance 10 |
| 22:18 | <heycam> | Hixie, yes... |
| 22:18 | <Hixie> | heycam: and your line has a corner at distance 10 |
| 22:18 | <Hixie> | heycam: does svg say if you lose the join or not? |
| 22:18 | <TabAtkins_> | <path d="M 10 10 h 40 v 40" stroke-dasharray="40 0" stroke="rgba(0,0,0,.5)" stroke-width="5" stroke-linecap="round" fill='transparent'/> |
| 22:19 | <Hixie> | heycam: does svg say if you lose the join or not? |
| 22:19 | <TabAtkins_> | <path d="M 10 10 h 40 v 40" stroke-dasharray="40 0" stroke="rgba(0,0,0,.5)" stroke-width="5" stroke-linecap="round" fill='transparent'/> |
| 22:19 | <TabAtkins_> | The corner is rounded, indicating the linecap is respected. (linejoin is miter by default, and so would produce a sharp corner if the segments were merged.) |
| 22:19 | <heycam> | sorry I'm confused :) |
| 22:20 | <TabAtkins_> | The corner is rounded, indicating the linecap is respected. (linejoin is miter by default, and so would produce a sharp corner if the segments were merged.) |
| 22:20 | <heycam> | sorry I'm confused :) |
| 22:20 | <TabAtkins_> | SVG doesn't mention anything about coalescing segments, so it looks like we cal call Chrome's behavior compliant. |
| 22:20 | <heycam> | ah the join |
| 22:20 | <TabAtkins_> | SVG doesn't mention anything about coalescing segments, so it looks like we cal call Chrome's behavior compliant. |
| 22:20 | <heycam> | ah the join |
| 22:20 | <TabAtkins_> | heycam: Yeah, we're trying to tell whether a 0-length "off" segment causes the two surrounding "on" segments to coalesce or not. |
| 22:20 | <heycam> | TabAtkins_, that corner is square in Firefox :) |
| 22:21 | <TabAtkins_> | heycam: Yeah, we're trying to tell whether a 0-length "off" segment causes the two surrounding "on" segments to coalesce or not. |
| 22:21 | <heycam> | TabAtkins_, that corner is square in Firefox :) |
| 22:21 | <TabAtkins_> | heycam: But the ends are round? |
| 22:21 | <heycam> | yeah |
| 22:21 | <TabAtkins_> | Then Firefox coalesces segments. |
| 22:21 | <TabAtkins_> | heycam: But the ends are round? |
| 22:21 | <heycam> | yeah |
| 22:21 | <TabAtkins_> | Then Firefox coalesces segments. |
| 22:21 | <heycam> | interesting |
| 22:22 | <heycam> | interesting |
| 22:22 | <TabAtkins_> | Which sounds like *more* work than just leaving it alone. |
| 22:22 | <TabAtkins_> | Which sounds like *more* work than just leaving it alone. |
| 22:22 | <heycam> | this is likely to be differences in the underlying graphics libraries |
| 22:22 | <heycam> | this is likely to be differences in the underlying graphics libraries |
| 22:22 | <TabAtkins_> | Could be, yeah. |
| 22:22 | <heycam> | which are doing the stroking |
| 22:22 | <Hixie> | ( http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1402 is a clearer test case) |
| 22:23 | <TabAtkins_> | Could be, yeah. |
| 22:23 | <heycam> | which are doing the stroking |
| 22:23 | <Hixie> | ( http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1402 is a clearer test case) |
| 22:23 | <Hixie> | hm, no opera on this machine, since i reset it the other day |
| 22:23 | <Hixie> | hm, no opera on this machine, since i reset it the other day |
| 22:23 | <Hixie> | what's the url to the opera nightly builds? |
| 22:23 | <heycam> | no dot on my opera |
| 22:23 | <Hixie> | i get no dot in safari either |
| 22:23 | <Hixie> | or firefox |
| 22:24 | <Hixie> | what's the url to the opera nightly builds? |
| 22:24 | <heycam> | no dot on my opera |
| 22:24 | <Hixie> | i get no dot in safari either |
| 22:24 | <Hixie> | or firefox |
| 22:24 | <Hixie> | incidentally, svg does say "Any zero length subpath shall not be stroked if the ‘stroke-linecap’ property has a value of butt but shall be stroked if the ‘stroke-linecap’ property has a value of round or square, producing respectively a circle or a square centered at the given point." |
| 22:25 | <Hixie> | incidentally, svg does say "Any zero length subpath shall not be stroked if the ‘stroke-linecap’ property has a value of butt but shall be stroked if the ‘stroke-linecap’ property has a value of round or square, producing respectively a circle or a square centered at the given point." |
| 22:25 | <Hixie> | not clear how you decide what direction the linecap should go |
| 22:25 | <Ms2ger> | Heh, "shall" |
| 22:25 | <heycam> | yes that's for subpaths though, not dashes |
| 22:25 | <Hixie> | not clear how you decide what direction the linecap should go |
| 22:25 | <Hixie> | yeah, but it's an example of how svg and canvas differ |
| 22:25 | <Ms2ger> | Heh, "shall" |
| 22:25 | <heycam> | yes that's for subpaths though, not dashes |
| 22:25 | <Hixie> | yeah, but it's an example of how svg and canvas differ |
| 22:25 | <Hixie> | on an almost identical issue |
| 22:25 | <heycam> | ok |
| 22:26 | <Hixie> | on an almost identical issue |
| 22:26 | <heycam> | ok |
| 22:26 | <Hixie> | oh there is an algorithm to determeine directionality |
| 22:26 | <Hixie> | it's deep in another chapter |
| 22:26 | <Hixie> | section F.5 |
| 22:26 | <Hixie> | oh there is an algorithm to determeine directionality |
| 22:26 | <Hixie> | it's deep in another chapter |
| 22:26 | <Hixie> | section F.5 |
| 22:26 | <heycam> | yeah that stuff really should be with the rest of the path stuff |
| 22:26 | <heycam> | it's like a little afterthought added for tricky cases :) |
| 22:26 | heycam | must go out for a bit |
| 22:27 | <heycam> | yeah that stuff really should be with the rest of the path stuff |
| 22:27 | <heycam> | it's like a little afterthought added for tricky cases :) |
| 22:27 | heycam | must go out for a bit |
| 22:28 | <Hixie> | "If a dash has zero length, linecaps are still added if the stroke-linecap values round and square are used." |
| 22:28 | <Hixie> | in 1.2T |
| 22:28 | <Hixie> | well implementations seem to disagree |
| 22:28 | <Hixie> | "If a dash has zero length, linecaps are still added if the stroke-linecap values round and square are used." |
| 22:28 | <Hixie> | in 1.2T |
| 22:28 | <Hixie> | well implementations seem to disagree |
| 22:28 | <TabAtkins_> | Yeah, I was just testing that. |
| 22:29 | <TabAtkins_> | Yeah, I was just testing that. |
| 22:29 | <Hixie> | oh actually my test checks something else |
| 22:29 | <TabAtkins_> | A dasharray of "0 10" should, by that line, draw a circle/square every 10px. |
| 22:29 | <Hixie> | oh actually my test checks something else |
| 22:29 | <TabAtkins_> | A dasharray of "0 10" should, by that line, draw a circle/square every 10px. |
| 22:29 | <Hixie> | yeah |
| 22:30 | <Hixie> | yeah |
| 22:30 | <TabAtkins_> | Heh, ".01 10" works in Chrome, but ".001 10" doesn't. Yay precision! |
| 22:31 | <TabAtkins_> | Heh, ".01 10" works in Chrome, but ".001 10" doesn't. Yay precision! |
| 22:32 | <TabAtkins_> | So I think that zero-length "off" segmetns should still split up a path into two segments, for consistency with SVG. |
| 22:32 | <TabAtkins_> | So I think that zero-length "off" segmetns should still split up a path into two segments, for consistency with SVG. |
| 22:32 | <TabAtkins_> | However, a zero-length "on" segment should act as normal for canvas (and have no drawing effect). |
| 22:33 | <TabAtkins_> | However, a zero-length "on" segment should act as normal for canvas (and have no drawing effect). |
| 22:33 | <Hixie> | consistency with the svg spec, or svg implementations? |
| 22:34 | <Hixie> | consistency with the svg spec, or svg implementations? |
| 22:34 | <Hixie> | i get different results in chrome, safari, and firefox for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1403 |
| 22:34 | <Hixie> | i get different results in chrome, safari, and firefox for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1403 |
| 22:34 | <zewt> | is the assumption that there's no hope of having the question answered by the svg spec and implementations reaching agreement? heh |
| 22:34 | <Hixie> | make that http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1404 |
| 22:34 | <Hixie> | 1403 is bogus |
| 22:35 | <zewt> | is the assumption that there's no hope of having the question answered by the svg spec and implementations reaching agreement? heh |
| 22:35 | <Hixie> | make that http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1404 |
| 22:35 | <Hixie> | 1403 is bogus |
| 22:35 | <TabAtkins_> | zewt: It'll be answered in SVG2 if we file a bug now. |
| 22:35 | <Hixie> | it's basically answered by svg now |
| 22:35 | <Hixie> | implementations just don't do it |
| 22:35 | <Hixie> | so the question is which should change |
| 22:35 | <TabAtkins_> | zewt: It'll be answered in SVG2 if we file a bug now. |
| 22:35 | <Hixie> | it's basically answered by svg now |
| 22:35 | <Hixie> | implementations just don't do it |
| 22:35 | <Hixie> | so the question is which should change |
| 22:35 | <zewt> | i mean, the question of whether to match the spec or implementations |
| 22:36 | <zewt> | i mean, the question of whether to match the spec or implementations |
| 22:38 | <Hixie> | ooh, opera nad firefox agree |
| 22:38 | <Hixie> | ooh, opera nad firefox agree |
| 22:43 | <Hixie> | i guess supporting zero-length "off" dashes isn't hard |
| 22:44 | <Hixie> | i guess supporting zero-length "off" dashes isn't hard |
| 22:53 | <Hixie> | i'm thinking people are going to want zero-length on dashes too though, for dotted lines... |
| 22:53 | <Hixie> | i'm thinking people are going to want zero-length on dashes too though, for dotted lines... |
| 22:53 | <TabAtkins_> | I do think that zero-length on dashes are useful (it's hacky to have to do a .01 length on dash). |
| 22:54 | <TabAtkins_> | I do think that zero-length on dashes are useful (it's hacky to have to do a .01 length on dash). |
| 22:54 | <Hixie> | what should happen if the dash is 1 0 0 0 0 0 0 0 0 0 ? |
| 22:54 | <Hixie> | i wonder if there's even any way to tell... |
| 22:54 | <Hixie> | what should happen if the dash is 1 0 0 0 0 0 0 0 0 0 ? |
| 22:54 | <Hixie> | i wonder if there's even any way to tell... |
| 22:54 | <TabAtkins_> | Depends on the drawing library. |
| 22:54 | <TabAtkins_> | If they draw each segment individually, you can tell with semi-transparent colors. |
| 22:54 | <TabAtkins_> | If they draw them all at the same time, you can't. |
| 22:55 | <TabAtkins_> | Depends on the drawing library. |
| 22:55 | <TabAtkins_> | If they draw each segment individually, you can tell with semi-transparent colors. |
| 22:55 | <TabAtkins_> | If they draw them all at the same time, you can't. |
| 22:55 | <Hixie> | canvas draws it at the same time |
| 22:55 | <Hixie> | canvas draws it at the same time |
| 22:57 | <TabAtkins_> | Then you can't tell. The multiple 0-length dash segments overwrite each other, and are then overwritten by the 1-length dash when it comes around again. |
| 22:58 | <TabAtkins_> | Then you can't tell. The multiple 0-length dash segments overwrite each other, and are then overwritten by the 1-length dash when it comes around again. |
| 22:59 | <Hixie> | ok 1 40 0 0 0 0 0 40 |
| 22:59 | <Hixie> | ok 1 40 0 0 0 0 0 40 |
| 22:59 | <Hixie> | i guess i should remove pairs of zeros that follow pairs of zeros |
| 23:00 | <Hixie> | i guess i should remove pairs of zeros that follow pairs of zeros |
| 23:01 | <TabAtkins_> | Yes, in that example you'll see a 1-dash, 40 space, 0-dash, 40 space. |
| 23:01 | <TabAtkins_> | Yes, in that example you'll see a 1-dash, 40 space, 0-dash, 40 space. |
| 23:01 | <TabAtkins_> | So removing pairs following the first pair should work, as you say. |
| 23:02 | <TabAtkins_> | So removing pairs following the first pair should work, as you say. |
| 23:03 | <Hixie> | actually i think what i should remove is any sequence of a zero off segment followed by a zero on segment |
| 23:03 | <Hixie> | actually i think what i should remove is any sequence of a zero off segment followed by a zero on segment |
| 23:03 | <TabAtkins_> | Yeah, that should work. |
| 23:03 | <Hixie> | including removing a leading zero / trailing zero pair |
| 23:04 | <TabAtkins_> | Yeah, that should work. |
| 23:04 | <Hixie> | including removing a leading zero / trailing zero pair |
| 23:04 | <Hixie> | (after doubling for for lengths) |
| 23:04 | <Hixie> | for odd |
| 23:04 | <Hixie> | (after doubling for for lengths) |
| 23:04 | <Hixie> | for odd |
| 23:06 | <TabAtkins_> | Removing a leading zero pair works if the third segment is non-zero. |
| 23:06 | <TabAtkins_> | Or rather, if there is *a* non-zero "on" segment. |
| 23:06 | <TabAtkins_> | Removing a leading zero pair works if the third segment is non-zero. |
| 23:06 | <TabAtkins_> | Or rather, if there is *a* non-zero "on" segment. |
| 23:07 | <TabAtkins_> | 0 0 0 10 should collapse to 0 10. |
| 23:07 | <Hixie> | if there's no non-zero on segments then the whole thing doesn't much matter |
| 23:07 | <TabAtkins_> | 0 0 0 10 should collapse to 0 10. |
| 23:07 | <Hixie> | if there's no non-zero on segments then the whole thing doesn't much matter |
| 23:07 | <Hixie> | oh wait right |
| 23:07 | <TabAtkins_> | Not true! All 0s still draws a single dot. |
| 23:07 | <Hixie> | i meant if there's no non-zero segments at all |
| 23:07 | <TabAtkins_> | The algorithm goes degenerate in that case, I guess. |
| 23:08 | <Hixie> | oh wait right |
| 23:08 | <TabAtkins_> | Not true! All 0s still draws a single dot. |
| 23:08 | <Hixie> | i meant if there's no non-zero segments at all |
| 23:08 | <TabAtkins_> | The algorithm goes degenerate in that case, I guess. |
| 23:08 | <TabAtkins_> | SVG chooses to just treat that as no dashing at all, and draws it solid. |
| 23:08 | <Hixie> | it treats it as 'none' |
| 23:08 | <TabAtkins_> | SVG chooses to just treat that as no dashing at all, and draws it solid. |
| 23:08 | <Hixie> | it treats it as 'none' |
| 23:08 | <Hixie> | whatever that means (solid?) |
| 23:08 | <Hixie> | (that's... unintuitive) |
| 23:08 | <TabAtkins_> | no dashes! |
| 23:08 | <Hixie> | mmmm |
| 23:09 | <Hixie> | whatever that means (solid?) |
| 23:09 | <Hixie> | (that's... unintuitive) |
| 23:09 | <TabAtkins_> | no dashes! |
| 23:09 | <Hixie> | mmmm |
| 23:10 | <Hixie> | what do you call the values in an array |
| 23:10 | <Hixie> | members of the array? |
| 23:11 | <Hixie> | what do you call the values in an array |
| 23:11 | <Hixie> | members of the array? |
| 23:11 | <TabAtkins_> | values works. |
| 23:11 | <Hixie> | values is the actual numbers |
| 23:11 | <Hixie> | i mean the buckets for the numbers |
| 23:12 | <TabAtkins_> | values works. |
| 23:12 | <Hixie> | values is the actual numbers |
| 23:12 | <Hixie> | i mean the buckets for the numbers |
| 23:12 | <Hixie> | i guess values still works |
| 23:12 | <Hixie> | nevermind |
| 23:12 | <Hixie> | i guess values still works |
| 23:12 | <Hixie> | nevermind |
| 23:12 | <TabAtkins_> | Hey, are you planning on adding markers a-la-SVG at some point? |
| 23:12 | <Hixie> | not currently |
| 23:13 | <TabAtkins_> | Hey, are you planning on adding markers a-la-SVG at some point? |
| 23:13 | <Hixie> | not currently |
| 23:13 | <Hixie> | (haven't had any requests for them) |
| 23:13 | <TabAtkins_> | Ok. Just asking, because markers depend on the subpaths, and if your dashing chops up the subpaths it'll make it harder for you. |
| 23:13 | <Hixie> | (haven't had any requests for them) |
| 23:13 | <TabAtkins_> | Ok. Just asking, because markers depend on the subpaths, and if your dashing chops up the subpaths it'll make it harder for you. |
| 23:14 | <Hixie> | i'd just do the markers before the chopping |
| 23:15 | <Hixie> | i'd just do the markers before the chopping |
| 23:15 | <Hixie> | that's not a big deal :-) |
| 23:15 | <Hixie> | that's not a big deal :-) |
| 23:16 | <TabAtkins_> | I think markers are still drawn on chopped-out segments, but if you meant just *placing* them before the chopping, then sure. |
| 23:16 | <TabAtkins_> | I think markers are still drawn on chopped-out segments, but if you meant just *placing* them before the chopping, then sure. |
| 23:16 | <Hixie> | markers are just filled shapes that are overlapped over the line when it is stroked right? |
| 23:16 | <TabAtkins_> | Yeah. |
| 23:17 | <Hixie> | markers are just filled shapes that are overlapped over the line when it is stroked right? |
| 23:17 | <TabAtkins_> | Yeah. |
| 23:17 | <Hixie> | so i would just take note of the direction and position that all the markers would have to be, then chop the line, then merge the two pieces of information into one path, then return that. |
| 23:17 | <TabAtkins_> | kk |
| 23:17 | <Hixie> | so i would just take note of the direction and position that all the markers would have to be, then chop the line, then merge the two pieces of information into one path, then return that. |
| 23:17 | <TabAtkins_> | kk |
| 23:19 | <Hixie> | when removing the last value if it's zero and the first value if it's zero, i need to make sure to then move the new last value to the front |
| 23:19 | <Hixie> | or move the new front value to the back |
| 23:19 | <Hixie> | any preference? |
| 23:19 | <Hixie> | when removing the last value if it's zero and the first value if it's zero, i need to make sure to then move the new last value to the front |
| 23:19 | <TabAtkins_> | front to the back! |
| 23:19 | <Hixie> | or move the new front value to the back |
| 23:19 | <Hixie> | any preference? |
| 23:19 | <TabAtkins_> | front to the back! |
| 23:19 | <Hixie> | actually... |
| 23:19 | <Hixie> | 0 40 40 0 drawn to a short line |
| 23:20 | <Hixie> | actually... |
| 23:20 | <Hixie> | 0 40 40 0 drawn to a short line |
| 23:20 | <Hixie> | short = 50 |
| 23:20 | <Hixie> | would be a dot then a 40 gap then a 10 line |
| 23:20 | <Hixie> | so we're wrong, we can't do that removal |
| 23:20 | <Hixie> | short = 50 |
| 23:20 | <Hixie> | would be a dot then a 40 gap then a 10 line |
| 23:20 | <Hixie> | so we're wrong, we can't do that removal |
| 23:20 | <Hixie> | so i have to deal with this case anyway in the stroking code |
| 23:20 | <Hixie> | so nevermind |
| 23:20 | <TabAtkins_> | You said you'd only remove 0 pairs in the beginning. |
| 23:20 | <TabAtkins_> | Not all zeros. |
| 23:21 | <Hixie> | so i have to deal with this case anyway in the stroking code |
| 23:21 | <Hixie> | so nevermind |
| 23:21 | <TabAtkins_> | You said you'd only remove 0 pairs in the beginning. |
| 23:21 | <TabAtkins_> | Not all zeros. |
| 23:28 | <Hixie> | ? |
| 23:28 | <Hixie> | ? |
| 23:28 | <Hixie> | "actually i think what i should remove is any sequence of a zero off segment followed by a zero on segment" is what i was referring to |
| 23:28 | <Hixie> | followed by the idea of extending that to wrap around |
| 23:28 | <TabAtkins_> | Oh, I didn't realize you were referring to a wraparound pair. |
| 23:29 | <Hixie> | "actually i think what i should remove is any sequence of a zero off segment followed by a zero on segment" is what i was referring to |
| 23:29 | <Hixie> | followed by the idea of extending that to wrap around |
| 23:29 | <TabAtkins_> | Oh, I didn't realize you were referring to a wraparound pair. |
| 23:29 | <Hixie> | but i can't do the extended case for wrap around, since it matters at the start of the stroke |
| 23:29 | <Hixie> | but i can't do the extended case for wrap around, since it matters at the start of the stroke |
| 23:29 | <TabAtkins_> | Yeah, don't do the wraparound. |
| 23:29 | <Hixie> | but if i don't do that, i need to deal with that case in the stroking code |
| 23:29 | <TabAtkins_> | Yeah, don't do the wraparound. |
| 23:29 | <Hixie> | at which point, i don't need to remove any |
| 23:29 | <Hixie> | since it doesn't gain me anything |
| 23:29 | <Hixie> | but if i don't do that, i need to deal with that case in the stroking code |
| 23:29 | <Hixie> | at which point, i don't need to remove any |
| 23:29 | <Hixie> | since it doesn't gain me anything |
| 23:29 | <TabAtkins_> | Note - it *doesn't* matter when you offset the dashes. |
| 23:29 | <Hixie> | right |
| 23:29 | <Hixie> | well |
| 23:29 | <Hixie> | right |
| 23:30 | <TabAtkins_> | Note - it *doesn't* matter when you offset the dashes. |
| 23:30 | <Hixie> | right |
| 23:30 | <Hixie> | well |
| 23:30 | <Hixie> | right |
| 23:30 | <TabAtkins_> | Modulo some specific cases, sure. |
| 23:30 | <TabAtkins_> | Modulo some specific cases, sure. |
| 23:31 | <TabAtkins_> | The problem is that the stroke isn't treated as an infinite line. If it were, you could safely remove wraparound pairs and just let the natural wrapping-around behavior work. |
| 23:31 | <TabAtkins_> | You'd get the cap of the off-screen segment that just touches the dash origin. |
| 23:32 | <TabAtkins_> | The problem is that the stroke isn't treated as an infinite line. If it were, you could safely remove wraparound pairs and just let the natural wrapping-around behavior work. |
| 23:32 | <TabAtkins_> | You'd get the cap of the off-screen segment that just touches the dash origin. |
| 23:34 | <Hixie> | yeah |
| 23:34 | <Hixie> | ok |
| 23:34 | <Hixie> | that's fine |
| 23:34 | <Hixie> | makes setting the dash list easy |
| 23:34 | <Hixie> | but now i have to deal with some szeros |
| 23:34 | <Hixie> | ok |
| 23:34 | <Hixie> | that's fine |
| 23:34 | <Hixie> | makes setting the dash list easy |
| 23:34 | <Hixie> | but now i have to deal with some szeros |
| 23:55 | <Hixie> | hmmm |
| 23:56 | <Hixie> | hmmm |
