| 00:05 | <rniwa> | smaug____: interesting |
| 00:05 | <rniwa> | smaug____: yeah |
| 00:05 | <rniwa> | smaug____: currently, there's a bit of timing issue with respect to mutation obserers |
| 00:06 | <rniwa> | smaug____: interesting |
| 00:06 | <rniwa> | smaug____: yeah |
| 00:06 | <rniwa> | smaug____: currently, there's a bit of timing issue with respect to mutation obserers |
| 00:06 | <rniwa> | smaug____: some editor developers have explictily told me that they want to see what changed in a given DOM transation |
| 00:06 | <rniwa> | smaug____: and we told them that they can use mutation observers |
| 00:06 | <rniwa> | smaug____: some editor developers have explictily told me that they want to see what changed in a given DOM transation |
| 00:06 | <rniwa> | smaug____: and we told them that they can use mutation observers |
| 00:06 | <rniwa> | smaug____: however, mutation observer only notifies at the end of a micro task |
| 00:06 | <rniwa> | smaug____: whereas multiple transactions can be added at once within a single micro task |
| 00:07 | <rniwa> | smaug____: however, mutation observer only notifies at the end of a micro task |
| 00:07 | <rniwa> | smaug____: whereas multiple transactions can be added at once within a single micro task |
| 00:07 | <rniwa> | I think AryehGregor and ehsan didn't want to add a duplicate API |
| 00:07 | <smaug____> | right |
| 00:07 | <rniwa> | I think AryehGregor and ehsan didn't want to add a duplicate API |
| 00:07 | <smaug____> | right |
| 00:07 | <rniwa> | also, the only case where catching the list of DOM mutations is important is when UA does something per user actions |
| 00:07 | <rniwa> | not then they themselves modify DOM |
| 00:07 | <rniwa> | because then they'll know what had happened |
| 00:08 | <rniwa> | also, the only case where catching the list of DOM mutations is important is when UA does something per user actions |
| 00:08 | <rniwa> | not then they themselves modify DOM |
| 00:08 | <rniwa> | because then they'll know what had happened |
| 00:08 | <rniwa> | but then the API is kind of inconsistent in that way :( |
| 00:08 | <rniwa> | haven't figured out a way to \ this yet |
| 00:08 | <rniwa> | but then the API is kind of inconsistent in that way :( |
| 00:08 | <rniwa> | haven't figured out a way to \ this yet |
| 00:08 | <rniwa> | smaug____: i'm all ears if you have some suggestion to resolve this issue |
| 00:09 | <rniwa> | smaug____: i'm all ears if you have some suggestion to resolve this issue |
| 00:09 | <smaug____> | need to think about, after reading the API |
| 00:09 | smaug____ | adds undomanager to the list of things to read and review |
| 00:10 | <smaug____> | need to think about, after reading the API |
| 00:10 | smaug____ | adds undomanager to the list of things to read and review |
| 00:10 | <rniwa> | smaug____: :) |
| 00:10 | <rniwa> | smaug____: i'm a bit bised here but undo manager api is one of exciting new APIs for those people who make productivity apps on the web |
| 00:11 | <rniwa> | smaug____: :) |
| 00:11 | <rniwa> | smaug____: i'm a bit bised here but undo manager api is one of exciting new APIs for those people who make productivity apps on the web |
| 00:11 | <smaug____> | what is "productivity apps" ? |
| 00:11 | <smaug____> | what is "productivity apps" ? |
| 00:11 | <rniwa> | smaug____: productivity apps as in word processors, spreadsheet app, presentation app, etc... |
| 00:11 | <rniwa> | smaug____: things that microsoft office do |
| 00:12 | <rniwa> | smaug____: productivity apps as in word processors, spreadsheet app, presentation app, etc... |
| 00:12 | <rniwa> | smaug____: things that microsoft office do |
| 00:12 | <rniwa> | smaug____: or any other business-related apps that create things |
| 00:12 | <rniwa> | smaug____: or any other business-related apps that create things |
| 00:12 | <smaug____> | ah, those things I don't use :) |
| 00:12 | <rniwa> | smaug____: as supposed to games, etc... |
| 00:12 | <smaug____> | not that I play games either :) |
| 00:13 | <smaug____> | ah, those things I don't use :) |
| 00:13 | <rniwa> | smaug____: as supposed to games, etc... |
| 00:13 | <rniwa> | i don't play games on my computer ever |
| 00:13 | <smaug____> | not that I play games either :) |
| 00:13 | <rniwa> | i don't play games on my computer ever |
| 00:13 | <rniwa> | so i'm less appreciative of lots of media/device related apis that have been introdued... |
| 00:13 | <rniwa> | introduced* |
| 00:13 | <rniwa> | so i'm less appreciative of lots of media/device related apis that have been introdued... |
| 00:13 | <rniwa> | introduced* |
| 00:16 | <smaug____> | I could still like to see good audio APIs, for music |
| 00:16 | <smaug____> | I could still like to see good audio APIs, for music |
| 00:17 | <rniwa> | smaug____: yeah, that's true |
| 00:17 | <rniwa> | smaug____: yeah, that's true |
| 00:26 | <zewt> | audio apis for music are trivial, compared to ones for games |
| 00:26 | <zewt> | audio apis for music are trivial, compared to ones for games |
| 00:35 | <smaug____> | zewt: really? requirements are higher, especially if you need to handle input and output |
| 00:35 | <smaug____> | zewt: really? requirements are higher, especially if you need to handle input and output |
| 00:44 | <zewt> | there's not a whole lot to "play song from URL"; there's a huge amount involved in games |
| 00:44 | <zewt> | there's not a whole lot to "play song from URL"; there's a huge amount involved in games |
| 00:46 | <smaug____> | zewt: I mean producing music |
| 00:47 | <smaug____> | zewt: I mean producing music |
| 00:47 | <smaug____> | games are easier, since for example with effects you don't have to be so exact. reverb can be just some reverb |
| 00:48 | <smaug____> | games are easier, since for example with effects you don't have to be so exact. reverb can be just some reverb |
| 00:48 | <smaug____> | with music you need to know the results exactly |
| 00:48 | <smaug____> | with music you need to know the results exactly |
| 00:51 | <zewt> | games are hard; you need low latency, and it wants lots of features (3d directionality, occlusions, time shifting, other filters, all of it changing in realtime) |
| 00:51 | <zewt> | games are hard; you need low latency, and it wants lots of features (3d directionality, occlusions, time shifting, other filters, all of it changing in realtime) |
| 00:51 | <smaug____> | you need very low latency with music |
| 00:51 | <smaug____> | and you want all features in music production |
| 00:51 | <zewt> | low latency playing back music is fairly straightforward; harder to do with complex effects |
| 00:52 | <smaug____> | you need very low latency with music |
| 00:52 | <smaug____> | and you want all features in music production |
| 00:52 | <zewt> | low latency playing back music is fairly straightforward; harder to do with complex effects |
| 00:52 | <smaug____> | I talking about a DAW implemented in HTML+JS :) |
| 00:53 | <smaug____> | I talking about a DAW implemented in HTML+JS :) |
| 01:01 | <Hixie> | i added some examples for arcTo() in http://www.whatwg.org/specs/web-apps/current-work/#building-paths |
| 01:02 | <Hixie> | i added some examples for arcTo() in http://www.whatwg.org/specs/web-apps/current-work/#building-paths |
| 01:03 | <Hixie> | and made arcTo() support ellipses, though i haven't added examples for that yet |
| 01:03 | <Hixie> | i'll make arc() support ellipses tomorrow |
| 01:03 | <Hixie> | (spent way too much time today drawing those danged diagrams) |
| 01:04 | <Hixie> | and made arcTo() support ellipses, though i haven't added examples for that yet |
| 01:04 | <Hixie> | i'll make arc() support ellipses tomorrow |
| 01:04 | <Hixie> | (spent way too much time today drawing those danged diagrams) |
| 01:51 | <MikeSmith> | scott_gonzalez: I have something ready for you guys to try out |
| 01:51 | <MikeSmith> | scott_gonzalez: I have something ready for you guys to try out |
| 01:51 | <scott_gonzalez> | MikeSmith: Awesome. Where can I download it? |
| 01:52 | <scott_gonzalez> | MikeSmith: Awesome. Where can I download it? |
| 01:52 | <MikeSmith> | scott_gonzalez: I've not written up the how-to on it yet, so lemme tell you here |
| 01:53 | <MikeSmith> | scott_gonzalez: I've not written up the how-to on it yet, so lemme tell you here |
| 01:53 | <MikeSmith> | first thing you need this: |
| 01:53 | <MikeSmith> | http://validator.github.com/jars/ |
| 01:53 | <MikeSmith> | http://validator.github.com/jars/jing-html.jar |
| 01:53 | <MikeSmith> | first thing you need this: |
| 01:53 | <MikeSmith> | http://validator.github.com/jars/ |
| 01:53 | <MikeSmith> | http://validator.github.com/jars/jing-html.jar |
| 01:54 | <scott_gonzalez> | got it |
| 01:54 | <scott_gonzalez> | got it |
| 01:55 | <MikeSmith> | then this: |
| 01:55 | <MikeSmith> | http://about.validator.nu/htmlparser/htmlparser-1.3.1.zip |
| 01:55 | <MikeSmith> | then this: |
| 01:55 | <MikeSmith> | http://about.validator.nu/htmlparser/htmlparser-1.3.1.zip |
| 01:56 | <MikeSmith> | you just need the jar file from that |
| 01:56 | <MikeSmith> | not the sources |
| 01:56 | <MikeSmith> | you just need the jar file from that |
| 01:56 | <MikeSmith> | not the sources |
| 01:56 | <MikeSmith> | htmlparser-1.3.1.jar |
| 01:56 | <scott_gonzalez> | ok |
| 01:57 | <MikeSmith> | htmlparser-1.3.1.jar |
| 01:57 | <scott_gonzalez> | ok |
| 01:57 | <MikeSmith> | then the last thing is this: |
| 01:57 | <MikeSmith> | http://kent.dl.sourceforge.net/sourceforge/saxon/saxonb9-1-0-2j.zip |
| 01:57 | <MikeSmith> | last jar needed |
| 01:58 | <MikeSmith> | then the last thing is this: |
| 01:58 | <MikeSmith> | http://kent.dl.sourceforge.net/sourceforge/saxon/saxonb9-1-0-2j.zip |
| 01:58 | <MikeSmith> | last jar needed |
| 01:59 | <scott_gonzalez> | The "saxonb9-1-0-2j.zip" file could not be found or is not available. Please select another file. |
| 01:59 | <scott_gonzalez> | The "saxonb9-1-0-2j.zip" file could not be found or is not available. Please select another file. |
| 01:59 | <MikeSmith> | oh |
| 01:59 | <scott_gonzalez> | http://sourceforge.net/projects/saxon/files/Saxon-B/9.1.0.8/saxonb9-1-0-8j.zip/download ? |
| 02:00 | <MikeSmith> | oh |
| 02:00 | <scott_gonzalez> | http://sourceforge.net/projects/saxon/files/Saxon-B/9.1.0.8/saxonb9-1-0-8j.zip/download ? |
| 02:00 | <MikeSmith> | yeah |
| 02:00 | <MikeSmith> | whatever the latest one is will be fine |
| 02:00 | <MikeSmith> | whatever the latest one is will be fine |
| 02:02 | <scott_gonzalez> | Do I need all of the saxon jars or just specific ones? |
| 02:02 | <scott_gonzalez> | Do I need all of the saxon jars or just specific ones? |
| 02:03 | <MikeSmith> | just the one |
| 02:04 | <MikeSmith> | just the one |
| 02:04 | <MikeSmith> | saxon9he.jar I think |
| 02:04 | <MikeSmith> | saxon9he.jar I think |
| 02:05 | <MikeSmith> | oh |
| 02:05 | <MikeSmith> | just saxon9.jar I guess |
| 02:05 | <scott_gonzalez> | ok |
| 02:05 | <MikeSmith> | yeah |
| 02:05 | <MikeSmith> | oh |
| 02:05 | <MikeSmith> | just saxon9.jar I guess |
| 02:05 | <scott_gonzalez> | ok |
| 02:05 | <MikeSmith> | yeah |
| 02:05 | <MikeSmith> | are all your docs HTML? I mean served as text/html? |
| 02:06 | <MikeSmith> | are all your docs HTML? I mean served as text/html? |
| 02:06 | <scott_gonzalez> | yeah |
| 02:06 | <scott_gonzalez> | yeah |
| 02:06 | <MikeSmith> | OK, so you need this: |
| 02:06 | <MikeSmith> | http://validator.github.com/schemas/html5.rnc |
| 02:06 | <MikeSmith> | OK, so you need this: |
| 02:06 | <MikeSmith> | http://validator.github.com/schemas/html5.rnc |
| 02:06 | <MikeSmith> | and this: |
| 02:06 | <MikeSmith> | http://validator.github.com/schemas/assertions.sch |
| 02:07 | <MikeSmith> | and this: |
| 02:07 | <MikeSmith> | http://validator.github.com/schemas/assertions.sch |
| 02:08 | <scott_gonzalez> | ok |
| 02:09 | <scott_gonzalez> | ok |
| 02:17 | <scott_gonzalez> | MikeSmith: I assume there's more (like how to run the validation)? |
| 02:17 | <MikeSmith> | yeah, sorry, got distracted |
| 02:18 | <scott_gonzalez> | MikeSmith: I assume there's more (like how to run the validation)? |
| 02:18 | <MikeSmith> | https://raw.github.com/validator/schemas/gh-pages/tools/validate-html.sh |
| 02:18 | <MikeSmith> | yeah, sorry, got distracted |
| 02:18 | <MikeSmith> | https://raw.github.com/validator/schemas/gh-pages/tools/validate-html.sh |
| 02:24 | <scott_gonzalez> | MikeSmith: https://gist.github.com/2026207 |
| 02:24 | MikeSmith | looks |
| 02:24 | <scott_gonzalez> | MikeSmith: https://gist.github.com/2026207 |
| 02:24 | MikeSmith | looks |
| 02:25 | <MikeSmith> | scott_gonzalez: seems like it's not finding the htmlparser in your java classpath |
| 02:25 | <MikeSmith> | maybe because of the filename |
| 02:26 | <MikeSmith> | scott_gonzalez: seems like it's not finding the htmlparser in your java classpath |
| 02:26 | <MikeSmith> | maybe because of the filename |
| 02:26 | <scott_gonzalez> | Oh, right, the saxon file is differnet. |
| 02:26 | <MikeSmith> | need to use htmlparser-1.3.1.jar instead |
| 02:26 | <scott_gonzalez> | Oh, right, the saxon file is differnet. |
| 02:26 | <MikeSmith> | need to use htmlparser-1.3.1.jar instead |
| 02:27 | <scott_gonzalez> | Yeah, that and saxon9.jar instead of saxon9he.jar |
| 02:27 | <scott_gonzalez> | It ran without errors that time. |
| 02:27 | <scott_gonzalez> | Let me try an invalid doc. |
| 02:28 | <scott_gonzalez> | Yeah, that and saxon9.jar instead of saxon9he.jar |
| 02:28 | <scott_gonzalez> | It ran without errors that time. |
| 02:28 | <scott_gonzalez> | Let me try an invalid doc. |
| 02:29 | <scott_gonzalez> | Seems to be working :-) |
| 02:29 | <scott_gonzalez> | Thanks. |
| 02:29 | <MikeSmith> | OK |
| 02:30 | <scott_gonzalez> | Seems to be working :-) |
| 02:30 | <scott_gonzalez> | Thanks. |
| 02:30 | <MikeSmith> | OK |
| 02:30 | <MikeSmith> | there are almost certainly some bugs in that schema that will cause it to report some attribute values as invalid when in fact they are valid |
| 02:30 | <MikeSmith> | there are almost certainly some bugs in that schema that will cause it to report some attribute values as invalid when in fact they are valid |
| 02:30 | <MikeSmith> | I don't know which ones |
| 02:30 | <MikeSmith> | but if you find any cases of that, let me know |
| 02:31 | <MikeSmith> | I don't know which ones |
| 02:31 | <MikeSmith> | but if you find any cases of that, let me know |
| 02:31 | <MikeSmith> | also, one big limitation of this is that it does not understand about data-* attributes |
| 02:31 | <scott_gonzalez> | I'll try to get this into our build system this week and I'll let you know how it goes. |
| 02:31 | <MikeSmith> | great |
| 02:31 | <scott_gonzalez> | Will it complain about them being invalid? |
| 02:31 | <MikeSmith> | also, one big limitation of this is that it does not understand about data-* attributes |
| 02:31 | <scott_gonzalez> | I'll try to get this into our build system this week and I'll let you know how it goes. |
| 02:31 | <MikeSmith> | great |
| 02:31 | <scott_gonzalez> | Will it complain about them being invalid? |
| 02:31 | <MikeSmith> | yes |
| 02:31 | <scott_gonzalez> | :-/ |
| 02:31 | <scott_gonzalez> | We can just filter that out on our end for now. |
| 02:32 | <MikeSmith> | yes |
| 02:32 | <scott_gonzalez> | :-/ |
| 02:32 | <scott_gonzalez> | We can just filter that out on our end for now. |
| 02:32 | <MikeSmith> | yeah, you'll need to do that |
| 02:32 | <MikeSmith> | yeah, you'll need to do that |
| 02:32 | <MikeSmith> | there is no way I can tell this jing tool about data-* attributes -- not without hacking it further |
| 02:33 | <MikeSmith> | there is no way I can tell this jing tool about data-* attributes -- not without hacking it further |
| 02:33 | <MikeSmith> | validator.nu uses a special pre-processing filter to deal with data-* |
| 02:33 | <MikeSmith> | validator.nu uses a special pre-processing filter to deal with data-* |
| 02:33 | <MikeSmith> | scott_gonzalez: anyway, one more thing: If you want it to run faster, you can cut out the second java call |
| 02:34 | <MikeSmith> | scott_gonzalez: anyway, one more thing: If you want it to run faster, you can cut out the second java call |
| 02:34 | <MikeSmith> | the one that uses the assertions.sch file |
| 02:34 | <MikeSmith> | of course you may miss some errors if you do that |
| 02:34 | <MikeSmith> | the one that uses the assertions.sch file |
| 02:34 | <scott_gonzalez> | What's that one doing? |
| 02:34 | <MikeSmith> | of course you may miss some errors if you do that |
| 02:34 | <scott_gonzalez> | What's that one doing? |
| 02:34 | <MikeSmith> | it's checking stuff that can't be checked with just the html5.rnc schema |
| 02:34 | <MikeSmith> | e.g., stuff that depends on checking the whole tree |
| 02:35 | <MikeSmith> | it's checking stuff that can't be checked with just the html5.rnc schema |
| 02:35 | <MikeSmith> | e.g., stuff that depends on checking the whole tree |
| 02:35 | <MikeSmith> | but it is relatively slow |
| 02:35 | <MikeSmith> | but it is relatively slow |
| 02:35 | <MikeSmith> | because I think it basically constructs a DOM and uses XSLT on the backend |
| 02:36 | <MikeSmith> | because I think it basically constructs a DOM and uses XSLT on the backend |
| 02:36 | <scott_gonzalez> | Ok, in that case we may just have three build targets for this. One for each of these and one that runs both of those targets. |
| 02:37 | <scott_gonzalez> | Ok, in that case we may just have three build targets for this. One for each of these and one that runs both of those targets. |
| 02:37 | <MikeSmith> | sounds good |
| 02:37 | <MikeSmith> | sounds good |
| 02:37 | <MikeSmith> | once you get it set up, I'd be curious to know about the times |
| 02:38 | <MikeSmith> | once you get it set up, I'd be curious to know about the times |
| 02:38 | <MikeSmith> | I think without that assertions check it will probably check most documents in 1 second or less |
| 02:38 | <MikeSmith> | probably 2 seconds at the very most |
| 02:38 | <MikeSmith> | I think without that assertions check it will probably check most documents in 1 second or less |
| 02:38 | <MikeSmith> | probably 2 seconds at the very most |
| 02:38 | <scott_gonzalez> | I'll let you know what we're seeing once it's all set up. |
| 02:38 | <MikeSmith> | thanks |
| 02:39 | <scott_gonzalez> | I'll let you know what we're seeing once it's all set up. |
| 02:39 | <MikeSmith> | thanks |
| 02:39 | <scott_gonzalez> | Thanks for getting this together. |
| 02:40 | <scott_gonzalez> | Thanks for getting this together. |
| 02:40 | <scott_gonzalez> | Now that I've got that working, I'm heading to bed. |
| 02:40 | <scott_gonzalez> | Have a good night. |
| 02:40 | <MikeSmith> | cheers |
| 02:41 | <scott_gonzalez> | Now that I've got that working, I'm heading to bed. |
| 02:41 | <scott_gonzalez> | Have a good night. |
| 02:41 | <MikeSmith> | cheers |
| 03:07 | <kennyluck> | I can't believe that CSS2.1 has been having an example that doesn't work in browsers for 5+ years. → http://www.w3.org/TR/CSS2/visuren.html#comp-float ('clear' doesn't apply to <span>) |
| 03:07 | <kennyluck> | I can't believe that CSS2.1 has been having an example that doesn't work in browsers for 5+ years. → http://www.w3.org/TR/CSS2/visuren.html#comp-float ('clear' doesn't apply to <span>) |
| 03:07 | <kennyluck> | more than 5+ years I would guess… anyway |
| 03:08 | <kennyluck> | more than 5+ years I would guess… anyway |
| 03:19 | <heycam> | Hixie, Ms2ger was right you can't distinguish (five doubles and a boolean) from (six doubles) -- all primitive types and DOMString are considered "undistinguishable" when it comes to overloading |
| 03:19 | <heycam> | Hixie, Ms2ger was right you can't distinguish (five doubles and a boolean) from (six doubles) -- all primitive types and DOMString are considered "undistinguishable" when it comes to overloading |
| 03:19 | Hixie | sad |
| 03:19 | <heycam> | Hixie, however you could always have a single operation and use "any" for the final arg type, if you must |
| 03:19 | <heycam> | Hixie, though I would agree with AryehGregor it sounds like it's verging on a confusing overload |
| 03:20 | Hixie | sad |
| 03:20 | <heycam> | Hixie, however you could always have a single operation and use "any" for the final arg type, if you must |
| 03:20 | <heycam> | Hixie, though I would agree with AryehGregor it sounds like it's verging on a confusing overload |
| 03:20 | <Hixie> | the specific example is arc() here: http://www.whatwg.org/specs/web-apps/current-work/#building-paths |
| 03:20 | <Hixie> | look at the domintro description to see what i'm going for |
| 03:20 | heycam | looks |
| 03:20 | <Hixie> | (and bask in my pretty drawings just before it, which i spent all afternoon working on) |
| 03:21 | <Hixie> | the specific example is arc() here: http://www.whatwg.org/specs/web-apps/current-work/#building-paths |
| 03:21 | <Hixie> | look at the domintro description to see what i'm going for |
| 03:21 | heycam | looks |
| 03:21 | <Hixie> | (and bask in my pretty drawings just before it, which i spent all afternoon working on) |
| 03:22 | <heycam> | Hixie, so this is arcTo()? |
| 03:22 | <Hixie> | no, arc() |
| 03:22 | <Hixie> | arcTo() is fine |
| 03:22 | <Hixie> | no ambiguity |
| 03:22 | <heycam> | oh below, I see |
| 03:23 | <heycam> | Hixie, so this is arcTo()? |
| 03:23 | <Hixie> | no, arc() |
| 03:23 | <Hixie> | arcTo() is fine |
| 03:23 | <Hixie> | no ambiguity |
| 03:23 | <heycam> | oh below, I see |
| 03:23 | <heycam> | optional arguments in the middle of the argument list? |
| 03:23 | <heycam> | please no |
| 03:23 | <heycam> | optional arguments in the middle of the argument list? |
| 03:23 | <heycam> | :)( |
| 03:23 | <heycam> | please no |
| 03:23 | <heycam> | :)( |
| 03:23 | <Hixie> | well it'd be silly to have the radii split apart with a boolean in the middle |
| 03:23 | <heycam> | put angles before radii? |
| 03:24 | <Hixie> | well it'd be silly to have the radii split apart with a boolean in the middle |
| 03:24 | <heycam> | put angles before radii? |
| 03:24 | <Hixie> | i can't change the existing signature |
| 03:24 | <Hixie> | the method today exists, just with one radius |
| 03:24 | <Hixie> | i can't change the existing signature |
| 03:24 | <Hixie> | the method today exists, just with one radius |
| 03:24 | <heycam> | oh |
| 03:25 | <heycam> | oh |
| 03:25 | <heycam> | I like the pictures though! ;) |
| 03:25 | <Hixie> | :-D |
| 03:25 | <heycam> | I like the pictures though! ;) |
| 03:25 | <Hixie> | :-D |
| 03:25 | <heycam> | hmm I don't have any good suggestion at the moment, except to say that I'm really not found of optional arguments in the middle of the arg list |
| 03:26 | <heycam> | hmm I don't have any good suggestion at the moment, except to say that I'm really not found of optional arguments in the middle of the arg list |
| 03:26 | <Hixie> | well i'm no fan either but i don't really see a better solution here |
| 03:27 | <Hixie> | well i'm no fan either but i don't really see a better solution here |
| 03:27 | <heycam> | separately named functions? |
| 03:27 | <heycam> | separately named functions? |
| 03:27 | <heycam> | passing [radiusX, radiusY] as the third argument? |
| 03:27 | <heycam> | (second suggestion slightly in jest) |
| 03:28 | <heycam> | passing [radiusX, radiusY] as the third argument? |
| 03:28 | <heycam> | (second suggestion slightly in jest) |
| 03:28 | <Hixie> | arc() and arcEllipse() would be kinda weird in this api, given the rest of it |
| 03:29 | <Hixie> | arc() and arcEllipse() would be kinda weird in this api, given the rest of it |
| 03:29 | <Hixie> | the array idea wouldn't be so bad if we were already doing it for all the coordinates, but doing it just for two radii, yeah |
| 03:29 | <Hixie> | the array idea wouldn't be so bad if we were already doing it for all the coordinates, but doing it just for two radii, yeah |
| 03:29 | <Hixie> | seems a bit silly |
| 03:29 | <Hixie> | seems a bit silly |
| 03:46 | <sicking> | Hixie: hey, do you have an eta for looking at the .readyState bugs that I filed? I have a feeling that if we're going to get MS to change their WebSocket implementation we need to act fast |
| 03:46 | <sicking> | Hixie: hey, do you have an eta for looking at the .readyState bugs that I filed? I have a feeling that if we're going to get MS to change their WebSocket implementation we need to act fast |
| 03:46 | sicking | isn't sure if IE10 previews has had EventSource support |
| 03:47 | sicking | isn't sure if IE10 previews has had EventSource support |
| 03:48 | <Hixie> | let me look now |
| 03:48 | <Hixie> | is this 16223 and 16224? |
| 03:49 | <Hixie> | let me look now |
| 03:49 | <Hixie> | is this 16223 and 16224? |
| 03:49 | <Hixie> | if you hadn't brought them to my attention, eta would have been several months :-) |
| 03:49 | <Hixie> | if you hadn't brought them to my attention, eta would have been several months :-) |
| 03:49 | <Hixie> | but eta can be a few minutes now |
| 03:49 | <Hixie> | sicking: what's wrong with "if (ws.readyState == 0) { ... }" ? |
| 03:50 | <Hixie> | but eta can be a few minutes now |
| 03:50 | <Hixie> | sicking: what's wrong with "if (ws.readyState == 0) { ... }" ? |
| 03:50 | <sicking> | Hixie: it's unreadable to humans |
| 03:50 | <Hixie> | it's readable fine |
| 03:50 | <sicking> | really? |
| 03:50 | <Hixie> | i can't say i've ever had a problem with xmlhttprequest.readyState == 4 |
| 03:51 | <sicking> | Hixie: it's unreadable to humans |
| 03:51 | <Hixie> | it's readable fine |
| 03:51 | <sicking> | really? |
| 03:51 | <Hixie> | i can't say i've ever had a problem with xmlhttprequest.readyState == 4 |
| 03:51 | <sicking> | you're the first person i hear say that |
| 03:51 | <sicking> | you're the first person i hear say that |
| 03:51 | <sicking> | well.. |
| 03:51 | <sicking> | ok |
| 03:51 | <sicking> | so constants are in general bad because they are hard to remember |
| 03:51 | <Hixie> | there's only like 3 states for eventsource and 4 states for websocket |
| 03:51 | <Hixie> | it's not like this is going to be a huge deal |
| 03:52 | <sicking> | well.. |
| 03:52 | <sicking> | ok |
| 03:52 | <sicking> | so constants are in general bad because they are hard to remember |
| 03:52 | <Hixie> | i agree in principle with using strings, and have moved to that style for new things |
| 03:52 | <Hixie> | there's only like 3 states for eventsource and 4 states for websocket |
| 03:52 | <Hixie> | it's not like this is going to be a huge deal |
| 03:52 | <Hixie> | i agree in principle with using strings, and have moved to that style for new things |
| 03:52 | <sicking> | which makes it even worse, since you'll likely have to listen for state 3 for ES and state 4 for WS |
| 03:52 | <Hixie> | but i'm not sure it's worth breaking shipping implementations here |
| 03:52 | <Hixie> | you don't in practice have to listen to any of the states |
| 03:52 | <Hixie> | but i'm not sure it's worth breaking shipping implementations here |
| 03:52 | <Hixie> | you just use the events |
| 03:52 | <Hixie> | you don't in practice have to listen to any of the states |
| 03:52 | <Hixie> | you just use the events |
| 03:52 | <sicking> | Hixie: i think we at mozilla would be happy to change both ES and WS, but I can't speak for other implementations of course |
| 03:52 | <Hixie> | honestly we could probably remove readyState and it wouldn't remove any use cases |
| 03:53 | <sicking> | Hixie: i think we at mozilla would be happy to change both ES and WS, but I can't speak for other implementations of course |
| 03:53 | <Hixie> | honestly we could probably remove readyState and it wouldn't remove any use cases |
| 03:53 | <sicking> | Hixie: sure, you'd just make developer ergonomics worse |
| 03:53 | <sicking> | but all apps would still be implementable |
| 03:53 | <sicking> | Hixie: sure, you'd just make developer ergonomics worse |
| 03:53 | <sicking> | but all apps would still be implementable |
| 03:53 | <Hixie> | how would you even use readyState in an app, other than for debugging? |
| 03:53 | <sicking> | if you want to push for removing readystate instead i'm ok with that. As long as we go for string values if we decide not to |
| 03:54 | <Hixie> | how would you even use readyState in an app, other than for debugging? |
| 03:54 | <Hixie> | i don't want to push for changing anything |
| 03:54 | <sicking> | if you want to push for removing readystate instead i'm ok with that. As long as we go for string values if we decide not to |
| 03:54 | <Hixie> | churn is bad |
| 03:54 | <Hixie> | i don't want to push for changing anything |
| 03:54 | <Hixie> | churn is bad |
| 03:54 | <Hixie> | we should just leave it as is and learn for the future |
| 03:54 | <Hixie> | we should just leave it as is and learn for the future |
| 03:54 | <sicking> | Hixie: ok, please state so in the bug so I can disagree with you there :) |
| 03:54 | <Hixie> | k :-) |
| 03:55 | <sicking> | Hixie: ok, please state so in the bug so I can disagree with you there :) |
| 03:55 | <Hixie> | k :-) |
| 03:55 | <sicking> | won't get to in until tomorrow, but i'll comment then |
| 03:56 | <sicking> | won't get to in until tomorrow, but i'll comment then |
| 03:57 | <Hixie> | sicking: fwiw in case there's anything else you want me to look at in the near future, my plan is to work on canvas for a while, and then work on this Web Intents stuff |
| 03:58 | <Hixie> | sicking: fwiw in case there's anything else you want me to look at in the near future, my plan is to work on canvas for a while, and then work on this Web Intents stuff |
| 03:58 | <Hixie> | sicking: and after that, go back to dealing with feedback in a first-come-first-served manner (at which i'm about 6 months behind) |
| 03:58 | <Hixie> | sicking: and after that, go back to dealing with feedback in a first-come-first-served manner (at which i'm about 6 months behind) |
| 03:58 | <Hixie> | sicking: for canvas i'm working down this list http://wiki.whatwg.org/wiki/Canvas#Proposals |
| 03:58 | <sicking> | Hixie: cool, thanks |
| 03:59 | <Hixie> | sicking: for canvas i'm working down this list http://wiki.whatwg.org/wiki/Canvas#Proposals |
| 03:59 | <Hixie> | sicking: but as usual i'm happy to prioritise stuff if there's anything urgent |
| 03:59 | <sicking> | Hixie: cool, thanks |
| 03:59 | <Hixie> | sicking: but as usual i'm happy to prioritise stuff if there's anything urgent |
| 03:59 | <sicking> | sounds good |
| 04:00 | <sicking> | sounds good |
| 04:02 | <zewt> | "consistency with XHR" seems more often an argument for bad things than good things, heh |
| 04:03 | <zewt> | "consistency with XHR" seems more often an argument for bad things than good things, heh |
| 04:16 | <rstuppi> | Does anyone know of an IRC channel for HTML5 Boilerplate questions? |
| 04:17 | <rstuppi> | Does anyone know of an IRC channel for HTML5 Boilerplate questions? |
| 04:28 | <kennyluck> | rstuppi, #html5 maybe? |
| 04:29 | <kennyluck> | rstuppi, #html5 maybe? |
| 05:24 | <MikeSmith> | should <meta name="description" itemprop="description" content="Some Description"> be valid? |
| 05:24 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=16342 |
| 05:25 | <MikeSmith> | should <meta name="description" itemprop="description" content="Some Description"> be valid? |
| 05:25 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=16342 |
| 05:33 | <MikeSmith> | nm |
| 05:33 | <MikeSmith> | found "If a meta element has an itemprop attribute, the name, http-equiv, and charset attributes must be omitted, and the content attribute must be present." |
| 05:33 | <MikeSmith> | nm |
| 05:33 | <MikeSmith> | found "If a meta element has an itemprop attribute, the name, http-equiv, and charset attributes must be omitted, and the content attribute must be present." |
| 05:34 | <MikeSmith> | such a great idea it was to split out microdata from the spec |
| 05:34 | <MikeSmith> | makes things much easier and clearer for users |
| 05:34 | <MikeSmith> | such a great idea it was to split out microdata from the spec |
| 05:34 | <MikeSmith> | makes things much easier and clearer for users |
| 05:47 | <Hixie> | MikeSmith: use the whatwg spec :-) |
| 05:48 | <Hixie> | MikeSmith: use the whatwg spec :-) |
| 05:49 | <MikeSmith> | Hixie: I like things "modularized" |
| 05:49 | <MikeSmith> | with extensibility |
| 05:50 | <MikeSmith> | Hixie: I like things "modularized" |
| 05:50 | <MikeSmith> | with extensibility |
| 05:50 | <MikeSmith> | plus a lot of ABNF |
| 05:51 | <MikeSmith> | plus a lot of ABNF |
| 05:51 | <MikeSmith> | then I know I'm reading a real spec |
| 05:51 | <MikeSmith> | then I know I'm reading a real spec |
| 05:52 | <Hixie> | mmm |
| 05:52 | <Hixie> | modularisation |
| 05:53 | <Hixie> | mmm |
| 05:53 | <Hixie> | modularisation |
| 06:01 | <MikeSmith> | Hixie: could you kindly update the spec to fix errors #5 and #6 here: http://validator.nu/?doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2F |
| 06:02 | <MikeSmith> | Hixie: could you kindly update the spec to fix errors #5 and #6 here: http://validator.nu/?doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2F |
| 06:02 | <MikeSmith> | stray </dt> end tags |
| 06:02 | <MikeSmith> | stray </dt> end tags |
| 06:03 | <MikeSmith> | about the other errors for itemprop, I dunno why it's reporting those but I will fix that in the validator |
| 06:04 | <MikeSmith> | about the other errors for itemprop, I dunno why it's reporting those but I will fix that in the validator |
| 06:04 | <MikeSmith> | hmm, weird |
| 06:04 | <MikeSmith> | http://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2F does not report those as errors |
| 06:05 | <MikeSmith> | hmm, weird |
| 06:05 | <MikeSmith> | http://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2F does not report those as errors |
| 06:05 | <MikeSmith> | must be I made a fix earlier that hsivonen hasn't pushed to validator.nu yet |
| 06:05 | <MikeSmith> | must be I made a fix earlier that hsivonen hasn't pushed to validator.nu yet |
| 06:06 | <Hixie> | when i run my script i only get: |
| 06:06 | <Hixie> | Possible conformance errors: |
| 06:06 | <Hixie> | when i run my script i only get: |
| 06:06 | <Hixie> | 14480.3-14480.77: info warning: The "cite" attribute on the "blockquote" element is not supported by browsers yet. |
| 06:06 | <Hixie> | 14501.3-14501.76: info warning: The "cite" attribute on the "blockquote" element is not supported by browsers yet. |
| 06:06 | <Hixie> | Possible conformance errors: |
| 06:06 | <Hixie> | 14480.3-14480.77: info warning: The "cite" attribute on the "blockquote" element is not supported by browsers yet. |
| 06:06 | <Hixie> | 67062.36-67063.88: info warning: The "cite" attribute on the "q" element is not supported by browsers yet. |
| 06:06 | <Hixie> | 120626.49-120626.126: error: Attribute "itemprop" not allowed on element "a" at this point. |
| 06:06 | <Hixie> | 120627.7-120627.113: error: Attribute "itemprop" not allowed on element "a" at this point. |
| 06:06 | <Hixie> | 14501.3-14501.76: info warning: The "cite" attribute on the "blockquote" element is not supported by browsers yet. |
| 06:06 | <Hixie> | 120628.5-120628.77: error: Attribute "itemprop" not allowed on element "a" at this point. |
| 06:06 | <Hixie> | 67062.36-67063.88: info warning: The "cite" attribute on the "q" element is not supported by browsers yet. |
| 06:06 | <Hixie> | 120626.49-120626.126: error: Attribute "itemprop" not allowed on element "a" at this point. |
| 06:06 | <Hixie> | 120627.7-120627.113: error: Attribute "itemprop" not allowed on element "a" at this point. |
| 06:06 | <Hixie> | 120628.5-120628.77: error: Attribute "itemprop" not allowed on element "a" at this point. |
| 06:06 | <MikeSmith> | hmm |
| 06:06 | <MikeSmith> | odd |
| 06:06 | <Hixie> | oh hm |
| 06:07 | <MikeSmith> | hmm |
| 06:07 | <MikeSmith> | odd |
| 06:07 | <Hixie> | oh hm |
| 06:07 | <Hixie> | the error does exist in the .../index file |
| 06:07 | <Hixie> | wonder why it's not in my source-validator version |
| 06:07 | <MikeSmith> | oh |
| 06:07 | <Hixie> | the error does exist in the .../index file |
| 06:07 | <Hixie> | wonder why it's not in my source-validator version |
| 06:07 | <MikeSmith> | oh |
| 06:08 | <Hixie> | oh i know why |
| 06:08 | <Hixie> | it's a bug in anolis or something |
| 06:08 | <Hixie> | i have a bunch of omitted </dt>s in the source |
| 06:08 | <Hixie> | oh i know why |
| 06:08 | <Hixie> | it's a bug in anolis or something |
| 06:08 | <Hixie> | i have a bunch of omitted </dt>s in the source |
| 06:08 | <Hixie> | and something in the pipeline is "helpfully" putting them back |
| 06:08 | <MikeSmith> | aha |
| 06:08 | <Hixie> | probably libxml2 misparsing again |
| 06:08 | <MikeSmith> | yep |
| 06:08 | <Hixie> | is html5lib fast yet? |
| 06:08 | <MikeSmith> | heh |
| 06:08 | <MikeSmith> | no, it's not, unfortunately |
| 06:09 | <Hixie> | and something in the pipeline is "helpfully" putting them back |
| 06:09 | <MikeSmith> | aha |
| 06:09 | <Hixie> | probably libxml2 misparsing again |
| 06:09 | <MikeSmith> | yep |
| 06:09 | <Hixie> | is html5lib fast yet? |
| 06:09 | <MikeSmith> | heh |
| 06:09 | <MikeSmith> | no, it's not, unfortunately |
| 06:14 | <MikeSmith> | Hixie: maybe it would be if you ran it under PyPy |
| 06:15 | <MikeSmith> | Hixie: maybe it would be if you ran it under PyPy |
| 07:24 | <ruby_on_tails> | hello |
| 07:24 | <zcorpan> | hello |
| 07:25 | <zcorpan> | hello |
| 07:25 | <ruby_on_tails> | i made a new tutorial, anyone wants to check it out ? |
| 07:25 | <ruby_on_tails> | i made a new tutorial, anyone wants to check it out ? |
| 07:26 | <ruby_on_tails> | Philip`: the issues i was facing yesterday is solved now :D |
| 07:26 | <ruby_on_tails> | Philip`: the issues i was facing yesterday is solved now :D |
| 07:31 | <zcorpan> | drop a link |
| 07:32 | <zcorpan> | drop a link |
| 07:34 | <annevk> | http://example.org/ |
| 07:35 | <annevk> | http://example.org/ |
| 07:36 | <zcorpan> | annoying that that redirects to another domain |
| 07:36 | <zcorpan> | annoying that that redirects to another domain |
| 07:40 | <annevk> | well since IANA handles it... it's not surprising |
| 07:41 | <annevk> | well since IANA handles it... it's not surprising |
| 07:54 | <hsivonen> | what can I do to learn to express myself in a way that chuck@jumis won't mischaracterize? |
| 07:54 | <hsivonen> | what can I do to learn to express myself in a way that chuck@jumis won't mischaracterize? |
| 07:55 | <annevk> | sing a song to the moon |
| 07:56 | <annevk> | sing a song to the moon |
| 07:57 | <annevk> | oh, even Mozilla is doing H264 now |
| 07:57 | <annevk> | also on desktop? |
| 07:57 | <annevk> | oh, even Mozilla is doing H264 now |
| 07:57 | <annevk> | also on desktop? |
| 07:59 | <hsivonen> | annevk: well, there's a discussion on whether Mozilla will be doing H.264 |
| 07:59 | <hsivonen> | annevk: Mozilla isn't doing it now |
| 07:59 | <hsivonen> | annevk: well, there's a discussion on whether Mozilla will be doing H.264 |
| 07:59 | <hsivonen> | annevk: Mozilla isn't doing it now |
| 07:59 | <annevk> | oh ok, sorry |
| 08:00 | <annevk> | oh ok, sorry |
| 08:00 | <hsivonen> | annevk: opinions vary. The spectrum is: nowhere, on mobile only, where systems codecs are available, everywhere |
| 08:00 | <hsivonen> | annevk: opinions vary. The spectrum is: nowhere, on mobile only, where systems codecs are available, everywhere |
| 08:01 | <hsivonen> | personally, I think the middle ground is worse than either end of the spectrum |
| 08:01 | <hsivonen> | personally, I think the middle ground is worse than either end of the spectrum |
| 08:13 | <MikeSmith> | hsivonen: has there been specific requests to support it on mobile? |
| 08:13 | <MikeSmith> | hsivonen: has there been specific requests to support it on mobile? |
| 08:13 | <MikeSmith> | I mean, people wanting to use particular sites |
| 08:14 | <MikeSmith> | I mean, people wanting to use particular sites |
| 08:16 | <hsivonen> | MikeSmith: I don't know |
| 08:17 | <hsivonen> | MikeSmith: I don't know |
| 08:17 | <hsivonen> | MikeSmith: there have been *lots* of specific requests for Flash support, though |
| 08:17 | <hsivonen> | MikeSmith: which for many sites amounts to roughly the same thing |
| 08:17 | <hsivonen> | e.g. Vimeo does H.264 <video> or Flash |
| 08:18 | <hsivonen> | MikeSmith: there have been *lots* of specific requests for Flash support, though |
| 08:18 | <hsivonen> | MikeSmith: which for many sites amounts to roughly the same thing |
| 08:18 | <hsivonen> | e.g. Vimeo does H.264 <video> or Flash |
| 08:18 | <MikeSmith> | OK |
| 08:18 | <MikeSmith> | OK |
| 08:18 | <MikeSmith> | yeah, I knew about the Flash demand |
| 08:18 | <MikeSmith> | that is an odd situation giving that Adobe is end-of-lifing mobile Flash |
| 08:19 | <MikeSmith> | yeah, I knew about the Flash demand |
| 08:19 | <MikeSmith> | that is an odd situation giving that Adobe is end-of-lifing mobile Flash |
| 08:19 | <hsivonen> | In the light of Adobe's recent announcements, I think it's safe to expect Adobe not to supply Flash Player for B2G |
| 08:19 | <MikeSmith> | yep |
| 08:19 | <hsivonen> | In the light of Adobe's recent announcements, I think it's safe to expect Adobe not to supply Flash Player for B2G |
| 08:19 | <MikeSmith> | yep |
| 08:19 | <hsivonen> | shumway won't be able to play H.264 wrapped in .swf without an H.264 decoder somewhere |
| 08:20 | <hsivonen> | shumway won't be able to play H.264 wrapped in .swf without an H.264 decoder somewhere |
| 08:20 | <MikeSmith> | I wonder what happened to all the plans for getting native WebM support on device hardware |
| 08:21 | <MikeSmith> | I wonder what happened to all the plans for getting native WebM support on device hardware |
| 08:21 | <MikeSmith> | there were lots of announcements about partnership with chipset vendors to support WebM |
| 08:21 | <MikeSmith> | there were lots of announcements about partnership with chipset vendors to support WebM |
| 08:21 | <MikeSmith> | but I don't recall seeing much news about any of it actually having shipped yet |
| 08:21 | <annevk> | hsivonen: I think we have non-desktop only at the moment |
| 08:21 | <hsivonen> | MikeSmith: I haven't seen news of anyone shipping device drivers that actually work |
| 08:22 | <MikeSmith> | but I don't recall seeing much news about any of it actually having shipped yet |
| 08:22 | <annevk> | hsivonen: I think we have non-desktop only at the moment |
| 08:22 | <hsivonen> | MikeSmith: I haven't seen news of anyone shipping device drivers that actually work |
| 08:22 | <hsivonen> | MikeSmith: it does look like hardware has shipped |
| 08:22 | <MikeSmith> | oh, ok |
| 08:22 | <hsivonen> | MikeSmith: it does look like hardware has shipped |
| 08:22 | <MikeSmith> | oh, ok |
| 08:22 | <hsivonen> | MikeSmith: WebM on Android seems to be full of FAIL on Google's part AFAICT |
| 08:22 | <MikeSmith> | that's disappointing |
| 08:22 | <hsivonen> | annevk: yeah, I think that's worse than supporting H.264 everywhere or supporting it nowhere |
| 08:23 | <hsivonen> | MikeSmith: WebM on Android seems to be full of FAIL on Google's part AFAICT |
| 08:23 | <MikeSmith> | that's disappointing |
| 08:23 | <hsivonen> | annevk: yeah, I think that's worse than supporting H.264 everywhere or supporting it nowhere |
| 08:23 | <hsivonen> | MikeSmith: promising to drop H.264 and then not dropping it in over a year is disappointing, too |
| 08:23 | <hsivonen> | MikeSmith: not getting the encoder competitive with x264 is disappointing |
| 08:23 | <hsivonen> | MikeSmith: etc. |
| 08:24 | <hsivonen> | MikeSmith: promising to drop H.264 and then not dropping it in over a year is disappointing, too |
| 08:24 | <hsivonen> | MikeSmith: not getting the encoder competitive with x264 is disappointing |
| 08:24 | <hsivonen> | MikeSmith: etc. |
| 08:24 | <zcorpan> | adobe promised webm support in flash, but that never happened either, did it? |
| 08:24 | <hsivonen> | zcorpan: that didn't happen, either |
| 08:25 | <zcorpan> | adobe promised webm support in flash, but that never happened either, did it? |
| 08:25 | <hsivonen> | zcorpan: that didn't happen, either |
| 08:26 | <zcorpan> | at least opera and mozilla kept their promise and shipped webm in a timely fashion :-) |
| 08:26 | <zcorpan> | at least opera and mozilla kept their promise and shipped webm in a timely fashion :-) |
| 08:26 | <hsivonen> | The way Google is handling WebM reminds me of how AOL handled Gecko |
| 08:26 | <hsivonen> | zcorpan: for some value of timely in the case of Mozilla |
| 08:26 | <hsivonen> | The way Google is handling WebM reminds me of how AOL handled Gecko |
| 08:26 | <hsivonen> | zcorpan: for some value of timely in the case of Mozilla |
| 08:26 | <hsivonen> | zcorpan: (not the video team's fault that Firefox 4 was so late) |
| 08:26 | <zcorpan> | yeah |
| 08:27 | <hsivonen> | zcorpan: (not the video team's fault that Firefox 4 was so late) |
| 08:27 | <zcorpan> | yeah |
| 08:27 | <hsivonen> | zcorpan: also, Mozilla could have done a better job at getting 3.6 out of circulation more quickly |
| 08:27 | <hsivonen> | zcorpan: also, Mozilla could have done a better job at getting 3.6 out of circulation more quickly |
| 08:27 | <zcorpan> | i.e. made extensions work in 4+ ? |
| 08:28 | <zcorpan> | i.e. made extensions work in 4+ ? |
| 08:28 | <hsivonen> | zcorpan: I was thinking of pushing updates more aggressively |
| 08:28 | <hsivonen> | zcorpan: there were *months* without prompted updates away from 3.6 |
| 08:28 | <hsivonen> | zcorpan: there were *months* without prompted updates away from 3.6 |
| 08:28 | <zcorpan> | i saw several people who intentionally didn't upgrade because their extensions weren't compatible |
| 08:28 | <hsivonen> | (let alone non-prompted updates) |
| 08:28 | <zcorpan> | (but i guess that's not the reason for the biggest chunk of 3.6 users since most users don't use extensions at all) |
| 08:29 | <zcorpan> | i saw several people who intentionally didn't upgrade because their extensions weren't compatible |
| 08:29 | <hsivonen> | (let alone non-prompted updates) |
| 08:29 | <zcorpan> | (but i guess that's not the reason for the biggest chunk of 3.6 users since most users don't use extensions at all) |
| 08:29 | <hsivonen> | "make extensions compatible" seems reasonable on surface, but it's technically not reasonable given how extensions work |
| 08:29 | <zcorpan> | and this was around the time of firefox *6* |
| 08:30 | <hsivonen> | "make extensions compatible" seems reasonable on surface, but it's technically not reasonable given how extensions work |
| 08:30 | <zcorpan> | and this was around the time of firefox *6* |
| 08:30 | <hsivonen> | the thing is that prior to JetPack, there wasn't an extension API in Firefox |
| 08:30 | <hsivonen> | the thing is that prior to JetPack, there wasn't an extension API in Firefox |
| 08:30 | <hsivonen> | there were extensions poking deep into implementation details |
| 08:31 | <hsivonen> | there were extensions poking deep into implementation details |
| 08:31 | <hsivonen> | the Firefox extension model is awesomely powerful if you only ever ship one version of Firefox |
| 08:32 | <hsivonen> | the Firefox extension model is awesomely powerful if you only ever ship one version of Firefox |
| 08:32 | <MikeSmith> | heh |
| 08:32 | <MikeSmith> | heh |
| 08:41 | <MikeSmith> | hsivonen: btw, I think you need to redeploy validator.nu |
| 08:41 | <MikeSmith> | hsivonen: btw, I think you need to redeploy validator.nu |
| 08:41 | <MikeSmith> | oh wait |
| 08:41 | <MikeSmith> | maybe you did already |
| 08:42 | <MikeSmith> | oh wait |
| 08:42 | <MikeSmith> | maybe you did already |
| 08:42 | <MikeSmith> | ah maybe not |
| 08:42 | <MikeSmith> | http://validator.nu/?doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2F |
| 08:42 | <MikeSmith> | ah maybe not |
| 08:42 | <MikeSmith> | http://validator.nu/?doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2F |
| 08:46 | <hsivonen> | MikeSmith: ok. rebuilding it now |
| 08:46 | <hsivonen> | MikeSmith: ok. rebuilding it now |
| 08:47 | <MikeSmith> | ok |
| 08:47 | <MikeSmith> | ok |
| 10:06 | <annevk> | pretty cool that all the DOM3 Events issues are being looked at again |
| 10:06 | <annevk> | hadn't expected that |
| 10:06 | <annevk> | pretty cool that all the DOM3 Events issues are being looked at again |
| 10:06 | <annevk> | hadn't expected that |
| 10:33 | <hsivonen> | MikeSmith: validator.nu build fails for me |
| 10:33 | <hsivonen> | MikeSmith: validator.nu build fails for me |
| 10:33 | <hsivonen> | MikeSmith: looks like embed.rnc forgets to remove itemref from the set of attributes it adds to <embed> |
| 10:34 | <hsivonen> | MikeSmith: looks like embed.rnc forgets to remove itemref from the set of attributes it adds to <embed> |
| 12:11 | <MikeSmith> | hsivonen: validator.nu is down |
| 12:12 | <MikeSmith> | hsivonen: validator.nu is down |
| 12:12 | <MikeSmith> | and prior to going down it was responding much more slowly than usual |
| 12:12 | <MikeSmith> | and prior to going down it was responding much more slowly than usual |
| 12:16 | <hsivonen> | MikeSmith: yeah, I had to kill it to relieve the server under too much use |
| 12:17 | <hsivonen> | MikeSmith: yeah, I had to kill it to relieve the server under too much use |
| 12:18 | <MikeSmith> | ok |
| 12:18 | <hsivonen> | the server is currently in a pretty bad shape |
| 12:18 | <MikeSmith> | ok |
| 12:18 | <hsivonen> | the server is currently in a pretty bad shape |
| 12:18 | <MikeSmith> | oh |
| 12:18 | <hsivonen> | an ls command has now taken almost a minute to run |
| 12:18 | <MikeSmith> | wow |
| 12:19 | <MikeSmith> | oh |
| 12:19 | <hsivonen> | an ls command has now taken almost a minute to run |
| 12:19 | <MikeSmith> | wow |
| 12:21 | <hsivonen> | LOL FAIL. someone in the logs is using an anymizer that announces it's an anonymizer in the UA string |
| 12:21 | <hsivonen> | LOL FAIL. someone in the logs is using an anymizer that announces it's an anonymizer in the UA string |
| 12:22 | <hsivonen> | I wonder if someone has made a Firefox extension that does site validation by POSTing to V.nu excessively |
| 12:23 | <hsivonen> | I wonder if someone has made a Firefox extension that does site validation by POSTing to V.nu excessively |
| 12:23 | <hsivonen> | most of the activity is POST with JSON output with Firefox Nightly UA strings |
| 12:24 | <hsivonen> | most of the activity is POST with JSON output with Firefox Nightly UA strings |
| 12:30 | <hsivonen> | ok. whoever is producing a Firefox extension that uploads stuff to V.nu needs to make the extension stop when it gets a non-200 response |
| 12:30 | <hsivonen> | ok. whoever is producing a Firefox extension that uploads stuff to V.nu needs to make the extension stop when it gets a non-200 response |
| 12:31 | <hsivonen> | MikeSmith: does V.nu start up for your locally given the current state of repos? |
| 12:32 | <hsivonen> | MikeSmith: does V.nu start up for your locally given the current state of repos? |
| 12:33 | <hsivonen> | one of these days I need to build some thingy that limits concurrent validation requests from one IP address |
| 12:33 | <hsivonen> | one of these days I need to build some thingy that limits concurrent validation requests from one IP address |
| 12:34 | <hsivonen> | MikeSmith: ok. validator.nu is back up |
| 12:35 | <hsivonen> | MikeSmith: ok. validator.nu is back up |
| 12:35 | <hsivonen> | MikeSmith: with old code, because the current repo state crashes at startup for me |
| 12:35 | <hsivonen> | I banned some IP numbers manually. this doesn't scale |
| 12:35 | <hsivonen> | MikeSmith: with old code, because the current repo state crashes at startup for me |
| 12:35 | <hsivonen> | I banned some IP numbers manually. this doesn't scale |
| 12:39 | <zcorpan> | hsivonen: ask @paulrouget to ask who the extension maker is on twitter |
| 12:39 | <zcorpan> | hsivonen: ask @paulrouget to ask who the extension maker is on twitter |
| 12:44 | <zcorpan> | or maybe someone took https://github.com/rogerjohansson/html5validator and didn't bother installing v.nu locally but instead just changed extensions.html5validator.validatorURL |
| 12:45 | <zcorpan> | or maybe someone took https://github.com/rogerjohansson/html5validator and didn't bother installing v.nu locally but instead just changed extensions.html5validator.validatorURL |
| 12:47 | <zcorpan> | hsivonen: http://superuser.com/questions/107228/is-there-a-html5-validator-plugin-for-firefox/259550#259550 |
| 12:48 | <zcorpan> | hsivonen: http://superuser.com/questions/107228/is-there-a-html5-validator-plugin-for-firefox/259550#259550 |
| 12:48 | <MikeSmith> | hsivonen: I will check out and build from a clean install |
| 12:56 | <MikeSmith> | hsivonen: |
| 12:57 | <MikeSmith> | Error: |
| 12:57 | <MikeSmith> | Error: |
| 12:57 | <MikeSmith> | Duplicate attribute “itemref”. |
| 12:57 | <MikeSmith> | File: file:/opt/archive/checker/syntax/relaxng/embed.rnc |
| 12:57 | <MikeSmith> | Line: 518 Col: 17 |
| 12:57 | <MikeSmith> | sorry, will fix that |
| 12:57 | <MikeSmith> | sorry, will fix that |
| 13:00 | <hsivonen> | I wonder how much this is an HTML5 validation perf issues and how much this is an HTML 4 validation (Schematron) perf issue |
| 13:00 | <hsivonen> | I wonder how much this is an HTML5 validation perf issues and how much this is an HTML 4 validation (Schematron) perf issue |
| 13:01 | <MikeSmith> | hsivonen: oh if you have people hitting it for HTML4 validation I would bet that could chew up a lot of resources |
| 13:02 | <MikeSmith> | hsivonen: oh if you have people hitting it for HTML4 validation I would bet that could chew up a lot of resources |
| 13:02 | <MikeSmith> | jing schematron is a hog even running it locally |
| 13:03 | <MikeSmith> | jing schematron is a hog even running it locally |
| 13:05 | <zcorpan> | hsivonen: i've filed an issue on the extension and edited the answer (though the edit needs to be reviewed until it shows up) |
| 13:06 | <zcorpan> | hsivonen: i've filed an issue on the extension and edited the answer (though the edit needs to be reviewed until it shows up) |
| 13:07 | <hsivonen> | zcorpan: thanks. roger johansson's extension may be what I'm seeing |
| 13:07 | <hsivonen> | maybe I should just move validator.nu and irssi to different servers, so slowness wouldn't bother me |
| 13:08 | <hsivonen> | zcorpan: thanks. roger johansson's extension may be what I'm seeing |
| 13:08 | <hsivonen> | maybe I should just move validator.nu and irssi to different servers, so slowness wouldn't bother me |
| 13:08 | <hsivonen> | html5.validator.nu is already separate |
| 13:08 | <hsivonen> | html5.validator.nu is already separate |
| 13:09 | <hsivonen> | zcorpan: that particular Stackoverflow answer doesn't explain this, because it points to html5.validator.nu instead of validator.nu |
| 13:10 | <hsivonen> | zcorpan: that particular Stackoverflow answer doesn't explain this, because it points to html5.validator.nu instead of validator.nu |
| 13:11 | <hsivonen> | whoa. does that extension post all pages you visit in whitelisted domains to the validator? |
| 13:11 | <hsivonen> | whoa. does that extension post all pages you visit in whitelisted domains to the validator? |
| 13:11 | <zcorpan> | it can be configured to do that, i think |
| 13:11 | <zcorpan> | hsivonen: it says validator.nu afaict |
| 13:12 | <zcorpan> | it can be configured to do that, i think |
| 13:12 | <zcorpan> | hsivonen: it says validator.nu afaict |
| 13:12 | <zcorpan> | hsivonen: btw it seems my answer has been reviewed and accepted now (at least it shows up for me in a private tab with turbo enabled) |
| 13:13 | <zcorpan> | hsivonen: btw it seems my answer has been reviewed and accepted now (at least it shows up for me in a private tab with turbo enabled) |
| 13:15 | <hsivonen> | of course it's my fault for not having defenses for this |
| 13:15 | hsivonen | is trying to figure out what the right defense would be |
| 13:15 | <hsivonen> | of course it's my fault for not having defenses for this |
| 13:15 | hsivonen | is trying to figure out what the right defense would be |
| 13:16 | <hsivonen> | stuff that I can think of: |
| 13:16 | <hsivonen> | 1) Move validator.nu to a new dedicated VM |
| 13:17 | <hsivonen> | stuff that I can think of: |
| 13:17 | <hsivonen> | 1) Move validator.nu to a new dedicated VM |
| 13:17 | <hsivonen> | 2) Stop offering HTML 4 validation in validator.nu; let the W3C deal with that |
| 13:17 | <hsivonen> | 2) Stop offering HTML 4 validation in validator.nu; let the W3C deal with that |
| 13:17 | <hsivonen> | 3) some kind of scoreboard for N most recent IP numbers and denying some requests depending on the scoreboard |
| 13:18 | <hsivonen> | 3) some kind of scoreboard for N most recent IP numbers and denying some requests depending on the scoreboard |
| 13:18 | <zcorpan> | (2) seems uncool i think |
| 13:18 | <zcorpan> | (2) seems uncool i think |
| 13:18 | <hsivonen> | the problem is I'm not sure what exactly the scoreboard should track in order to not to limit reasonable use |
| 13:19 | <hsivonen> | the problem is I'm not sure what exactly the scoreboard should track in order to not to limit reasonable use |
| 13:19 | <hsivonen> | 4) Rewrite HTML 4 validation Schematron in Java |
| 13:19 | <StoneCypher> | lol yeah |
| 13:19 | <StoneCypher> | let's do it in *java* |
| 13:19 | <hsivonen> | 4) Rewrite HTML 4 validation Schematron in Java |
| 13:19 | StoneCypher | facepalm |
| 13:19 | <StoneCypher> | lol yeah |
| 13:19 | <StoneCypher> | let's do it in *java* |
| 13:19 | StoneCypher | facepalm |
| 13:19 | <zcorpan> | StoneCypher: you know v.nu is written in java, right? |
| 13:19 | <StoneCypher> | why would i know that |
| 13:20 | <zcorpan> | StoneCypher: you know v.nu is written in java, right? |
| 13:20 | <StoneCypher> | all i know is java isn't a particularly good choice for that kind of tool |
| 13:20 | <StoneCypher> | why would i know that |
| 13:20 | <StoneCypher> | all i know is java isn't a particularly good choice for that kind of tool |
| 13:20 | <zcorpan> | dunno, it says so in http://about.validator.nu/ |
| 13:20 | <StoneCypher> | and? |
| 13:20 | <zcorpan> | dunno, it says so in http://about.validator.nu/ |
| 13:20 | <StoneCypher> | and? |
| 13:20 | <StoneCypher> | "you know this random characteristic of this site you've never bothered to open, right? well it says so right in the corner" |
| 13:20 | <zcorpan> | ... |
| 13:21 | <StoneCypher> | "you know this random characteristic of this site you've never bothered to open, right? well it says so right in the corner" |
| 13:21 | <zcorpan> | ... |
| 13:21 | <StoneCypher> | yes, that's an ellipsis. |
| 13:21 | <StoneCypher> | it generally indicates text that has been removed for brevity's sake, not a pause. |
| 13:21 | <StoneCypher> | yes, that's an ellipsis. |
| 13:21 | <StoneCypher> | it generally indicates text that has been removed for brevity's sake, not a pause. |
| 13:21 | <StoneCypher> | technically it's a greek tricolon, but insert standard rabble here about getting it something someone will recognize instead of being correct |
| 13:22 | <StoneCypher> | technically it's a greek tricolon, but insert standard rabble here about getting it something someone will recognize instead of being correct |
| 13:24 | <MikeSmith> | hsivonen: I vote for 4 |
| 13:24 | <Philip`> | 5) Get MikeSmith to rewrite HTML 4 validation Schematron in Java |
| 13:24 | <MikeSmith> | heh |
| 13:25 | <MikeSmith> | hsivonen: I vote for 4 |
| 13:25 | <Philip`> | 5) Get MikeSmith to rewrite HTML 4 validation Schematron in Java |
| 13:25 | <MikeSmith> | heh |
| 13:25 | <hsivonen> | this same IP keeps hitting validator.nu over and over again oblivious to the 403 |
| 13:25 | <hsivonen> | this same IP keeps hitting validator.nu over and over again oblivious to the 403 |
| 13:26 | <StoneCypher> | so block it |
| 13:26 | <MikeSmith> | hsivonen: I can write up the HTML4 assertions checker if you can make time to review it |
| 13:26 | <hsivonen> | MikeSmith: deal |
| 13:26 | <StoneCypher> | so block it |
| 13:26 | <MikeSmith> | hsivonen: I can write up the HTML4 assertions checker if you can make time to review it |
| 13:26 | <hsivonen> | MikeSmith: deal |
| 13:26 | <zcorpan> | (6) hunt down the user(s) of the extension and beat them up with a cricket bat |
| 13:26 | <MikeSmith> | I reckon I can get it done by next week or next next |
| 13:27 | <zcorpan> | (6) hunt down the user(s) of the extension and beat them up with a cricket bat |
| 13:27 | <MikeSmith> | I reckon I can get it done by next week or next next |
| 13:27 | <hsivonen> | 6) Make even validator.nu default to HTML5 instead of defaulting to 4 or 5 depending on doctype |
| 13:27 | <hsivonen> | 6) Make even validator.nu default to HTML5 instead of defaulting to 4 or 5 depending on doctype |
| 13:27 | <MikeSmith> | hsivonen: I think it makes sense to re-implement it to not just real schematron, regardless of this current load issue |
| 13:28 | <MikeSmith> | hsivonen: I think it makes sense to re-implement it to not just real schematron, regardless of this current load issue |
| 13:28 | <MikeSmith> | *to not use real schematron |
| 13:28 | <hsivonen> | MikeSmith: ok |
| 13:28 | <MikeSmith> | *to not use real schematron |
| 13:28 | <hsivonen> | MikeSmith: ok |
| 13:29 | <zcorpan> | though of course, letting html4 validation take resources away from making html5 validation better is also uncool |
| 13:29 | <zcorpan> | though of course, letting html4 validation take resources away from making html5 validation better is also uncool |
| 13:29 | <hsivonen> | StoneCypher: http://about.validator.nu/#faq |
| 13:30 | <hsivonen> | StoneCypher: http://about.validator.nu/#faq |
| 13:30 | <MikeSmith> | hsivonen: fwiw, I think the W3C systems team could give you some concrete suggestions on how to automatically deal with the bad-behaving IPs |
| 13:30 | <StoneCypher> | hsivonen: what about it |
| 13:30 | <MikeSmith> | the have a lot of experience at it :) |
| 13:30 | <MikeSmith> | hsivonen: fwiw, I think the W3C systems team could give you some concrete suggestions on how to automatically deal with the bad-behaving IPs |
| 13:30 | <StoneCypher> | hsivonen: what about it |
| 13:30 | <MikeSmith> | the have a lot of experience at it :) |
| 13:31 | <hsivonen> | StoneCypher: the answer to "Java? Eww. Why didn’t you write it in Python or Ruby?" |
| 13:31 | <hsivonen> | StoneCypher: the answer to "Java? Eww. Why didn’t you write it in Python or Ruby?" |
| 13:32 | <StoneCypher> | i didn't say that |
| 13:32 | <StoneCypher> | those two languages would be even worse choices. |
| 13:32 | <hsivonen> | StoneCypher: and your choice would be? |
| 13:32 | <StoneCypher> | i didn't say that |
| 13:32 | <StoneCypher> | those two languages would be even worse choices. |
| 13:32 | <hsivonen> | StoneCypher: and your choice would be? |
| 13:32 | StoneCypher | sighs |
| 13:32 | <StoneCypher> | do we really need to get into a clueless java zealot argument |
| 13:33 | StoneCypher | sighs |
| 13:33 | <StoneCypher> | do we really need to get into a clueless java zealot argument |
| 13:33 | <StoneCypher> | that was 15 minutes ago |
| 13:33 | <StoneCypher> | c, c++, ocaml, haskell, factor, fortress, basically anything with real direct access to strings and no boxing overhead |
| 13:33 | <StoneCypher> | that was 15 minutes ago |
| 13:33 | <StoneCypher> | c, c++, ocaml, haskell, factor, fortress, basically anything with real direct access to strings and no boxing overhead |
| 13:33 | <StoneCypher> | no, not haskell, it's got immutable strings |
| 13:33 | <StoneCypher> | but yeah, next bring up the alioth shootout |
| 13:33 | <StoneCypher> | then insist there's nothing wrong with java, that hotspot is magic and takes out all the overhead |
| 13:34 | <StoneCypher> | no, not haskell, it's got immutable strings |
| 13:34 | <StoneCypher> | but yeah, next bring up the alioth shootout |
| 13:34 | <StoneCypher> | then insist there's nothing wrong with java, that hotspot is magic and takes out all the overhead |
| 13:34 | StoneCypher | starts writing out the flowchart to save time |
| 13:34 | Philip` | wonders why StoneCypher anticipates that any discussion will turn into an argument, and preemptively starts the argument himself |
| 13:34 | StoneCypher | starts writing out the flowchart to save time |
| 13:34 | Philip` | wonders why StoneCypher anticipates that any discussion will turn into an argument, and preemptively starts the argument himself |
| 13:34 | <StoneCypher> | Philip`: i don't assume that. |
| 13:34 | <StoneCypher> | Philip`: i do assume that discussions that start with someone inventing false quotes for someone else will, however, becuse they already have. |
| 13:34 | <StoneCypher> | because* |
| 13:35 | <StoneCypher> | Philip`: i don't assume that. |
| 13:35 | <StoneCypher> | Philip`: i do assume that discussions that start with someone inventing false quotes for someone else will, however, becuse they already have. |
| 13:35 | <StoneCypher> | because* |
| 13:37 | <annevk> | it's not a false quote |
| 13:37 | <annevk> | it's a quote from the FAQ |
| 13:37 | <annevk> | it's not a false quote |
| 13:37 | <annevk> | it's a quote from the FAQ |
| 13:38 | <StoneCypher> | uh. |
| 13:38 | <StoneCypher> | try again, anne. |
| 13:39 | <StoneCypher> | uh. |
| 13:39 | <StoneCypher> | try again, anne. |
| 13:39 | StoneCypher | sighs and just doesn't bother |
| 13:39 | StoneCypher | sighs and just doesn't bother |
| 13:42 | <MikeSmith> | hsivonen: fix for the breakage pushed |
| 13:42 | <MikeSmith> | just backed out my previous change |
| 13:42 | <MikeSmith> | sorry again |
| 13:43 | <MikeSmith> | hsivonen: fix for the breakage pushed |
| 13:43 | <MikeSmith> | just backed out my previous change |
| 13:43 | <MikeSmith> | sorry again |
| 13:46 | <hsivonen> | MikeSmith: verified. thanks. I'll redeploy |
| 13:47 | <hsivonen> | MikeSmith: verified. thanks. I'll redeploy |
| 13:47 | <MikeSmith> | I will attempt to be more careful in the future |
| 13:47 | <MikeSmith> | I will attempt to be more careful in the future |
| 13:49 | <MikeSmith> | hsivonen: btw, after trying out a few different ways of doing command-line validation (using that VerifierCommandLine class, using Jing directly), it's even more clear to me now that the HTTP interface is just way better than the alternatives |
| 13:49 | <MikeSmith> | certainly much faster |
| 13:50 | <MikeSmith> | hsivonen: btw, after trying out a few different ways of doing command-line validation (using that VerifierCommandLine class, using Jing directly), it's even more clear to me now that the HTTP interface is just way better than the alternatives |
| 13:50 | <MikeSmith> | certainly much faster |
| 13:56 | <zcorpan> | nice, "cssom !" with ddg gives me the editor's draft of cssom |
| 13:56 | <zcorpan> | nice, "cssom !" with ddg gives me the editor's draft of cssom |
| 13:57 | <hsivonen> | Ask.com: How do I get rid of the toolbar? DuckDuckGo: How do I make it the default? |
| 13:58 | <hsivonen> | Ask.com: How do I get rid of the toolbar? DuckDuckGo: How do I make it the default? |
| 13:58 | <MikeSmith> | hsivonen: I wonder how many people who set out download and build the validator code never get past the downloading-dependencies + downloading-local-entities stage |
| 13:59 | <MikeSmith> | hsivonen: I wonder how many people who set out download and build the validator code never get past the downloading-dependencies + downloading-local-entities stage |
| 13:59 | <MikeSmith> | if we could make that step less time-consuming and painful, that would be good |
| 13:59 | <hsivonen> | MikeSmith: probably many |
| 13:59 | <hsivonen> | yeah |
| 14:00 | <MikeSmith> | if we could make that step less time-consuming and painful, that would be good |
| 14:00 | <hsivonen> | MikeSmith: probably many |
| 14:00 | <hsivonen> | yeah |
| 14:00 | <hsivonen> | dunno how to do that without a weekly test to see if the download locations still work |
| 14:00 | <MikeSmith> | yeah |
| 14:00 | hsivonen | mumbles about cool URIs not changing |
| 14:00 | <hsivonen> | dunno how to do that without a weekly test to see if the download locations still work |
| 14:00 | <MikeSmith> | yeah |
| 14:00 | hsivonen | mumbles about cool URIs not changing |
| 14:00 | <MikeSmith> | oh, that reminds me, I still did not actually land the patch that downloads the w3c stuff from the zip file I made |
| 14:00 | <StoneCypher> | hateoas is still the best acronym alive |
| 14:01 | <MikeSmith> | oh, that reminds me, I still did not actually land the patch that downloads the w3c stuff from the zip file I made |
| 14:01 | <StoneCypher> | hateoas is still the best acronym alive |
| 14:01 | <hsivonen> | Do I have to host all the libs somewhere and go through all the license compliance issues *again* from a slightly different perspective? |
| 14:01 | <hsivonen> | Do I have to host all the libs somewhere and go through all the license compliance issues *again* from a slightly different perspective? |
| 14:02 | <MikeSmith> | even hosting all the libs, user still has to download them all |
| 14:02 | <MikeSmith> | don't know how to get around that |
| 14:02 | <MikeSmith> | even hosting all the libs, user still has to download them all |
| 14:02 | <MikeSmith> | don't know how to get around that |
| 14:02 | <zcorpan> | hmm. maybe i should file bugs instead of sending emails to www-style |
| 14:03 | <zcorpan> | hmm. maybe i should file bugs instead of sending emails to www-style |
| 14:03 | <hsivonen> | MikeSmith: https://twitter.com/#!/tbroyer/status/175603090978897921 |
| 14:04 | <hsivonen> | MikeSmith: https://twitter.com/#!/tbroyer/status/175603090978897921 |
| 14:04 | <MikeSmith> | heh |
| 14:04 | <MikeSmith> | ain't that the truth |
| 14:04 | <MikeSmith> | heh |
| 14:04 | <MikeSmith> | ain't that the truth |
| 14:09 | <MikeSmith> | hsivonen: I just sent you that zip patch for review |
| 14:09 | <MikeSmith> | if you have time to take a quick look at it I'd appreciate it |
| 14:10 | <MikeSmith> | hsivonen: I just sent you that zip patch for review |
| 14:10 | <MikeSmith> | if you have time to take a quick look at it I'd appreciate it |
| 14:10 | <MikeSmith> | I think it's sane but always possible there's something I didn't consider |
| 14:10 | <MikeSmith> | anyway, it's only 10 lines or so |
| 14:10 | <MikeSmith> | I think it's sane but always possible there's something I didn't consider |
| 14:10 | <MikeSmith> | anyway, it's only 10 lines or so |
| 14:11 | <hsivonen> | MikeSmith: looking |
| 14:12 | <hsivonen> | MikeSmith: looking |
| 14:25 | <annevk> | http://www.w3.org/TR/2012/WD-webmessaging-20120313/#messageeventinit should maybe use sequence<MessagePort>? ? |
| 14:26 | <annevk> | http://www.w3.org/TR/2012/WD-webmessaging-20120313/#messageeventinit should maybe use sequence<MessagePort>? ? |
| 14:35 | <zcorpan> | ok so for the collapsing table quirk, which browser behavior should i spec? i'm a bit tempted to follow ie compat quirks since i guess that's what everyone else is trying to emulate |
| 14:36 | <zcorpan> | ok so for the collapsing table quirk, which browser behavior should i spec? i'm a bit tempted to follow ie compat quirks since i guess that's what everyone else is trying to emulate |
| 14:37 | <smaug____> | zcorpan: I suggest asking dbaron and bz |
| 14:37 | <zcorpan> | but maybe mozilla's behavior is better since it can look at just the child boxes |
| 14:37 | <smaug____> | zcorpan: I suggest asking dbaron and bz |
| 14:37 | <zcorpan> | but maybe mozilla's behavior is better since it can look at just the child boxes |
| 14:37 | <zcorpan> | smaug____: they'll just say i should spec mozilla's behavior :-P |
| 14:38 | <zcorpan> | smaug____: they'll just say i should spec mozilla's behavior :-P |
| 14:38 | <smaug____> | so they'll give you the right answer :) |
| 14:38 | <smaug____> | so they'll give you the right answer :) |
| 14:39 | <zcorpan> | ie doesn't collapse the table when there's a caption, but the other browsers do that |
| 14:39 | <smaug____> | zcorpan: but really, dbaron and bz have years of experience on that stuff. |
| 14:39 | <annevk> | the Mozilla "do whatever is best for the web mantra" seems to be about over these days :p |
| 14:39 | <zcorpan> | ie doesn't collapse the table when there's a caption, but the other browsers do that |
| 14:39 | <smaug____> | zcorpan: but really, dbaron and bz have years of experience on that stuff. |
| 14:39 | <annevk> | the Mozilla "do whatever is best for the web mantra" seems to be about over these days :p |
| 14:39 | <zcorpan> | smaug____: oh sure |
| 14:39 | <annevk> | or maybe it's just highly aligned with whatever is best for Gecko |
| 14:39 | <smaug____> | annevk: bah |
| 14:40 | <zcorpan> | smaug____: oh sure |
| 14:40 | <annevk> | or maybe it's just highly aligned with whatever is best for Gecko |
| 14:40 | <smaug____> | annevk: bah |
| 14:41 | <zcorpan> | i think i'll go with making the quirk have affect for the minimal set needed, which i think is a combination of ie and mozilla: if there's a table-caption, table-row-group, table-header-group or table-footer-group box child of a table, don't apply the quirk |
| 14:42 | <zcorpan> | i think i'll go with making the quirk have affect for the minimal set needed, which i think is a combination of ie and mozilla: if there's a table-caption, table-row-group, table-header-group or table-footer-group box child of a table, don't apply the quirk |
| 14:42 | <zcorpan> | (moz also applies the quirk for inline-table and when there's a table-caption) |
| 14:43 | <zcorpan> | (moz also applies the quirk for inline-table and when there's a table-caption) |
| 14:45 | <zcorpan> | hmm, ie also doesn't apply the quirk when there's a table-column (but does apply it if there's just a table-column-group) |
| 14:46 | <zcorpan> | hmm, ie also doesn't apply the quirk when there's a table-column (but does apply it if there's just a table-column-group) |
| 14:46 | <annevk> | oh yes, W3C starts publishing drafts documenting a single method: http://www.w3.org/TR/hr-time/ |
| 14:46 | <annevk> | oh yes, W3C starts publishing drafts documenting a single method: http://www.w3.org/TR/hr-time/ |
| 14:47 | <zcorpan> | let's split html5 into lots of drafts where each idl member gets its own spec |
| 14:47 | <MikeSmith> | modularization |
| 14:48 | <zcorpan> | let's split html5 into lots of drafts where each idl member gets its own spec |
| 14:48 | <MikeSmith> | modularization |
| 14:48 | <MikeSmith> | it's clearly catching on |
| 14:48 | <MikeSmith> | it's clearly catching on |
| 14:48 | <MikeSmith> | XHTML 1.1 Modularization for HTML5 |
| 14:48 | <annevk> | and constants: http://www.w3.org/TR/2012/CR-navigation-timing-20120313/#performancenavigation ? |
| 14:49 | <MikeSmith> | XHTML 1.1 Modularization for HTML5 |
| 14:49 | <annevk> | and constants: http://www.w3.org/TR/2012/CR-navigation-timing-20120313/#performancenavigation ? |
| 15:10 | <zcorpan> | ok http://simon.html5.org/specs/quirks-mode#the-collapsing-table-quirk specced |
| 15:10 | <zcorpan> | ok http://simon.html5.org/specs/quirks-mode#the-collapsing-table-quirk specced |
| 15:11 | <zcorpan> | that leaves the table cell nowrap quirk |
| 15:11 | <zcorpan> | that leaves the table cell nowrap quirk |
| 15:42 | <MikeSmith> | zcorpan, annevk - fyi the CSS validator now has CSS3 support |
| 15:42 | <MikeSmith> | zcorpan, annevk - fyi the CSS validator now has CSS3 support |
| 15:42 | <MikeSmith> | so please actually check the pubrules CSS reports |
| 15:42 | <MikeSmith> | and if it is reporting false positives, file bugs |
| 15:43 | <MikeSmith> | so please actually check the pubrules CSS reports |
| 15:43 | <MikeSmith> | and if it is reporting false positives, file bugs |
| 15:46 | <MikeSmith> | is there no :marker pseudo-element? |
| 15:46 | <MikeSmith> | is there no :marker pseudo-element? |
| 15:46 | <MikeSmith> | wait I know there isn't |
| 15:46 | <MikeSmith> | just what can I use instead of :marker |
| 15:47 | <MikeSmith> | wait I know there isn't |
| 15:47 | <MikeSmith> | just what can I use instead of :marker |
| 15:47 | <MikeSmith> | ah wait |
| 15:48 | <MikeSmith> | ah wait |
| 15:48 | <MikeSmith> | it's just not in either of the selectors specs |
| 15:48 | <MikeSmith> | but instead only in the lists and counters module |
| 15:48 | <MikeSmith> | but instead only in the lists and counters module |
| 15:48 | <MikeSmith> | modularization ftw |
| 15:49 | <MikeSmith> | modularization ftw |
| 15:55 | <zcorpan> | [nowrap] turned out to be two quirks |
| 15:56 | <zcorpan> | [nowrap] turned out to be two quirks |
| 16:01 | <dglazkov> | good morning, Whatwg! |
| 16:02 | <dglazkov> | good morning, Whatwg! |
| 16:02 | <zcorpan> | two quirks specced today (and one dropped) |
| 16:03 | <zcorpan> | two quirks specced today (and one dropped) |
| 16:06 | <MikeSmith> | zcorpan, annevk - https://www.w3.org/Bugs/Public/enter_bug.cgi?product=CSSValidator |
| 16:06 | <MikeSmith> | zcorpan, annevk - https://www.w3.org/Bugs/Public/enter_bug.cgi?product=CSSValidator |
| 16:06 | <zcorpan> | MikeSmith: ok |
| 16:07 | <zcorpan> | MikeSmith: ok |
| 16:07 | <MikeSmith> | Yves did a lot of work to get it updated, so would be great if we can help get it improved |
| 16:07 | <MikeSmith> | Yves did a lot of work to get it updated, so would be great if we can help get it improved |
| 16:07 | <MikeSmith> | really doesn't help much that the rules are spread out across 30+ different specs |
| 16:07 | <MikeSmith> | I mean as far as trying to implement a validator for it |
| 16:08 | <MikeSmith> | really doesn't help much that the rules are spread out across 30+ different specs |
| 16:08 | <MikeSmith> | I mean as far as trying to implement a validator for it |
| 16:56 | <bga> | IE correctly parse unknown css properties and put it in CSSRuleStyleDeclaration |
| 16:56 | <bga> | IE correctly parse unknown css properties and put it in CSSRuleStyleDeclaration |
| 17:13 | <bga> | background: url("linear-gradient: red white"); |
| 17:13 | <bga> | background: url("linear-gradient: red white"); |
| 17:13 | <bga> | custom handler that return svg w/ gradient |
| 17:14 | <bga> | custom handler that return svg w/ gradient |
| 17:22 | <MikeSmith> | hsivonen: so with the zip-file thing added, even over my really slow connection, it takes only 10 mins to completely download and build and run the validator code |
| 17:22 | <MikeSmith> | hsivonen: so with the zip-file thing added, even over my really slow connection, it takes only 10 mins to completely download and build and run the validator code |
| 17:22 | <MikeSmith> | which isn't very harsh |
| 17:23 | <MikeSmith> | which isn't very harsh |
| 17:34 | <AryehGregor> | Gmail's important-conversation-marking works really well. |
| 17:35 | <AryehGregor> | Now it's correctly marking transforms-related discussions as important because of the people involved. |
| 17:35 | <AryehGregor> | Now it's correctly marking transforms-related discussions as important because of the people involved. |
| 17:39 | <MikeSmith> | AryehGregor: point is also about what it recognizes as not important I guess |
| 17:39 | <Hixie> | i think my arcTo() relying on transforms to get rotations makes no sense |
| 17:39 | <Hixie> | so i'm adding a 'rotation' argument to arcTo() |
| 17:39 | <Hixie> | also, i think instead of overloading arc() i'm just going to make a method ellipse() |
| 17:39 | <Hixie> | that is basically the same but not for circular arcs |
| 17:40 | <MikeSmith> | AryehGregor: point is also about what it recognizes as not important I guess |
| 17:40 | <Hixie> | i think my arcTo() relying on transforms to get rotations makes no sense |
| 17:40 | <Hixie> | so i'm adding a 'rotation' argument to arcTo() |
| 17:40 | <Hixie> | also, i think instead of overloading arc() i'm just going to make a method ellipse() |
| 17:40 | <Hixie> | that is basically the same but not for circular arcs |
| 17:40 | AryehGregor | is all in favor of a separate method instead of overloading |
| 17:41 | AryehGregor | is all in favor of a separate method instead of overloading |
| 17:41 | <MikeSmith> | Hixie: what AryehGregor said |
| 17:41 | <MikeSmith> | in general |
| 17:42 | <MikeSmith> | Hixie: what AryehGregor said |
| 17:42 | <MikeSmith> | in general |
| 17:42 | <AryehGregor> | Overloading is only a good idea when you have two different calls that mean basically the same thing, like with different argument types or optional arguments or things conceptually similar to that. |
| 17:42 | <AryehGregor> | The canvas API seems very over-overloaded already. |
| 17:42 | <AryehGregor> | Overloading is only a good idea when you have two different calls that mean basically the same thing, like with different argument types or optional arguments or things conceptually similar to that. |
| 17:42 | <AryehGregor> | The canvas API seems very over-overloaded already. |
| 17:43 | <TabAtkins_> | +1 to ellipse(). |
| 17:43 | <TabAtkins_> | +1 to ellipse(). |
| 17:43 | <MikeSmith> | the canvas API seems like not a model to be followed |
| 17:43 | <AryehGregor> | I haven't tried using it, but I saw operations along the lines of "if you provide six floats it behaves one way, but if you provide eight floats then the fifth and sixth arguments mean something different and the seventh and eighth mean the same as the old fifth and sixth". |
| 17:43 | <AryehGregor> | Which I guess is just optional arguments in the middle. |
| 17:43 | <AryehGregor> | But it seems quite horrible. |
| 17:43 | <TabAtkins_> | Yeah, the drawImage function. |
| 17:44 | <MikeSmith> | the canvas API seems like not a model to be followed |
| 17:44 | <AryehGregor> | I haven't tried using it, but I saw operations along the lines of "if you provide six floats it behaves one way, but if you provide eight floats then the fifth and sixth arguments mean something different and the seventh and eighth mean the same as the old fifth and sixth". |
| 17:44 | <AryehGregor> | Which I guess is just optional arguments in the middle. |
| 17:44 | <AryehGregor> | But it seems quite horrible. |
| 17:44 | <TabAtkins_> | Yeah, the drawImage function. |
| 17:44 | <TabAtkins_> | Which, as usual, should have just taken some objects instead. |
| 17:44 | <TabAtkins_> | Which, as usual, should have just taken some objects instead. |
| 17:44 | <AryehGregor> | :( |
| 17:45 | <AryehGregor> | :( |
| 17:45 | <TabAtkins_> | drawImage(img,{x,y,w,h}, {w,y,w,h}) |
| 17:45 | <TabAtkins_> | drawImage(img,{x,y,w,h}, {w,y,w,h}) |
| 17:46 | <AryehGregor> | Do you mean arrays there? |
| 17:46 | <AryehGregor> | Do you mean arrays there? |
| 17:46 | <TabAtkins_> | No, but arrays might work too, since it's always the w,h that are omittable. |
| 17:47 | <TabAtkins_> | No, but arrays might work too, since it's always the w,h that are omittable. |
| 17:47 | <AryehGregor> | Oh, you mean an object like {x: 7, y: 5} or something. |
| 17:47 | <TabAtkins_> | yeah |
| 17:47 | <AryehGregor> | I think an array is shorter and clearer here. |
| 17:47 | <TabAtkins_> | probably, yeah. |
| 17:48 | <AryehGregor> | Oh, you mean an object like {x: 7, y: 5} or something. |
| 17:48 | <TabAtkins_> | yeah |
| 17:48 | <AryehGregor> | I think an array is shorter and clearer here. |
| 17:48 | <TabAtkins_> | probably, yeah. |
| 17:48 | <TabAtkins_> | ctx.drawImage(src, [0,0], [0,0,50,100]) |
| 17:48 | <TabAtkins_> | Makes sense to me. |
| 17:48 | <TabAtkins_> | ctx.drawImage(src, [0,0], [0,0,50,100]) |
| 17:48 | <TabAtkins_> | Makes sense to me. |
| 17:49 | <AryehGregor> | The trick is whether the third and fourth parameters are width/height, or the x/y coords of a second corner. |
| 17:49 | <AryehGregor> | You just have to rely on platform consistency for that. |
| 17:50 | <AryehGregor> | The trick is whether the third and fourth parameters are width/height, or the x/y coords of a second corner. |
| 17:50 | <AryehGregor> | You just have to rely on platform consistency for that. |
| 17:50 | <MikeSmith> | hey TabAtkins_ |
| 17:50 | <TabAtkins_> | Oh, true. That's a potential advantage of objects. Naming is always useful. |
| 17:50 | <TabAtkins_> | MikeSmith: Yo! |
| 17:50 | <MikeSmith> | hey TabAtkins_ |
| 17:50 | <TabAtkins_> | Oh, true. That's a potential advantage of objects. Naming is always useful. |
| 17:50 | <TabAtkins_> | MikeSmith: Yo! |
| 17:50 | <MikeSmith> | where you been man? |
| 17:50 | <TabAtkins_> | AryehGregor: Luckily the xywh pattern is pretty well established. |
| 17:50 | <TabAtkins_> | MikeSmith: At sxsw |
| 17:50 | <MikeSmith> | ah |
| 17:50 | <MikeSmith> | yeah |
| 17:50 | <MikeSmith> | Gingerman? |
| 17:50 | <MikeSmith> | B-side? |
| 17:51 | <MikeSmith> | where you been man? |
| 17:51 | <TabAtkins_> | AryehGregor: Luckily the xywh pattern is pretty well established. |
| 17:51 | <TabAtkins_> | MikeSmith: At sxsw |
| 17:51 | <MikeSmith> | ah |
| 17:51 | <MikeSmith> | yeah |
| 17:51 | <MikeSmith> | Gingerman? |
| 17:51 | <MikeSmith> | B-side? |
| 17:51 | <TabAtkins_> | Spent every night at ginger man, yeah. |
| 17:52 | <TabAtkins_> | Met *tons* of people that I'd only known through Twitter. Lots of fun all around. |
| 17:52 | <TabAtkins_> | And our panel went even better than last year. |
| 17:52 | <MikeSmith> | great |
| 17:53 | <TabAtkins_> | Met *tons* of people that I'd only known through Twitter. Lots of fun all around. |
| 17:53 | <TabAtkins_> | And our panel went even better than last year. |
| 17:53 | <MikeSmith> | great |
| 17:53 | <MikeSmith> | someday I will get back to Austin |
| 17:53 | <MikeSmith> | someday I will get back to Austin |
| 17:54 | <MikeSmith> | TabAtkins_: btw I'm still wondering about your claim that emscripten had overcome the "order of magnitude" gap |
| 17:54 | <TabAtkins_> | MikeSmith: Heard it on Twitter, with a link to a github issue that I skimmed. |
| 17:54 | <MikeSmith> | hmm |
| 17:55 | <MikeSmith> | TabAtkins_: btw I'm still wondering about your claim that emscripten had overcome the "order of magnitude" gap |
| 17:55 | <TabAtkins_> | MikeSmith: Heard it on Twitter, with a link to a github issue that I skimmed. |
| 17:55 | <MikeSmith> | hmm |
| 17:55 | <TabAtkins_> | It would be from about two weeks ago, and I think it was a RT, so it would be hard for me to find. |
| 17:55 | <TabAtkins_> | It would be from about two weeks ago, and I think it was a RT, so it would be hard for me to find. |
| 17:55 | <gsnedders> | TabAtkins_: It depends on the code, though. |
| 17:55 | <TabAtkins_> | gsnedders: Yeah, definitely. |
| 17:55 | <MikeSmith> | afaict from Joel Webber postings that gap is still there |
| 17:55 | <MikeSmith> | gsnedders: of course |
| 17:55 | <MikeSmith> | also like recent JSC refactoring |
| 17:56 | <gsnedders> | TabAtkins_: It depends on the code, though. |
| 17:56 | <TabAtkins_> | gsnedders: Yeah, definitely. |
| 17:56 | <MikeSmith> | afaict from Joel Webber postings that gap is still there |
| 17:56 | <MikeSmith> | gsnedders: of course |
| 17:56 | <MikeSmith> | also like recent JSC refactoring |
| 17:56 | <MikeSmith> | rewriting |
| 17:56 | <MikeSmith> | rewriting |
| 17:56 | <MikeSmith> | from dude |
| 17:56 | <gsnedders> | https://github.com/kripken/emscripten/issues/22#issuecomment-4201138 is the origin |
| 17:56 | <MikeSmith> | forgot his name |
| 17:56 | <MikeSmith> | from dude |
| 17:56 | <MikeSmith> | guy from Purdue |
| 17:56 | <gsnedders> | https://github.com/kripken/emscripten/issues/22#issuecomment-4201138 is the origin |
| 17:56 | <MikeSmith> | forgot his name |
| 17:56 | <MikeSmith> | guy from Purdue |
| 17:56 | <TabAtkins_> | gsnedders: That's it! Thanks. |
| 17:57 | <TabAtkins_> | gsnedders: That's it! Thanks. |
| 17:58 | <MikeSmith> | holy fuck |
| 17:58 | <MikeSmith> | " I can now definitively state that emscripten+ff has broken the order-of-magnitude barrier w.r.t. C++." |
| 17:58 | <MikeSmith> | from the man himself |
| 17:59 | <MikeSmith> | holy fuck |
| 17:59 | <MikeSmith> | " I can now definitively state that emscripten+ff has broken the order-of-magnitude barrier w.r.t. C++." |
| 17:59 | <MikeSmith> | from the man himself |
| 17:59 | <MikeSmith> | that's pretty impressive |
| 17:59 | <jgraham> | (using objects in places where you might have a tight loop seems like it could impose some performance cost) |
| 18:00 | <jgraham> | (using objects in places where you might have a tight loop seems like it could impose some performance cost) |
| 18:03 | <Philip`> | MikeSmith: Where "from the man himself" means "from an inherently biased person"? |
| 18:03 | <Philip`> | MikeSmith: Where "from the man himself" means "from an inherently biased person"? |
| 18:03 | <MikeSmith> | heh |
| 18:04 | <MikeSmith> | heh |
| 18:04 | <MikeSmith> | he is the foremost EXPERT in his field man |
| 18:04 | <MikeSmith> | he is the foremost EXPERT in his field man |
| 18:04 | <TabAtkins_> | Don't get all wikipedian on us, jgraham . |
| 18:04 | <MikeSmith> | as am I in the field of smokable varieties of THC |
| 18:05 | <TabAtkins_> | Don't get all wikipedian on us, jgraham . |
| 18:05 | <MikeSmith> | as am I in the field of smokable varieties of THC |
| 18:05 | <TabAtkins_> | Who invented data urls? I want to buy that person a beer. |
| 18:06 | <TabAtkins_> | Who invented data urls? I want to buy that person a beer. |
| 18:07 | <TabAtkins_> | Ooh, and now I get to set up hg on my work box. |
| 18:07 | <TabAtkins_> | Yay? |
| 18:07 | <TabAtkins_> | Ooh, and now I get to set up hg on my work box. |
| 18:07 | <TabAtkins_> | Yay? |
| 18:08 | <WeirdAl> | TabAtkins_: hope you like Xerox |
| 18:08 | <WeirdAl> | http://tools.ietf.org/html/rfc2397 |
| 18:08 | <WeirdAl> | TabAtkins_: hope you like Xerox |
| 18:08 | <WeirdAl> | http://tools.ietf.org/html/rfc2397 |
| 18:08 | <TabAtkins_> | Dammit, Larry Masinter! |
| 18:08 | <MikeSmith> | LOL |
| 18:08 | <TabAtkins_> | Okay, I'll still buy him a beer. And then run away. |
| 18:08 | <MikeSmith> | dude |
| 18:09 | <TabAtkins_> | Dammit, Larry Masinter! |
| 18:09 | <MikeSmith> | LOL |
| 18:09 | <TabAtkins_> | Okay, I'll still buy him a beer. And then run away. |
| 18:09 | <WeirdAl> | I have no idea who the guy is, actually - a name in our industry I've never heard. |
| 18:09 | <MikeSmith> | dude |
| 18:09 | <WeirdAl> | I have no idea who the guy is, actually - a name in our industry I've never heard. |
| 18:09 | <MikeSmith> | you owe Larry some serious ove |
| 18:09 | <MikeSmith> | WeirdAl: Larry is god |
| 18:09 | <MikeSmith> | like Loki |
| 18:09 | <MikeSmith> | or the demiurge |
| 18:10 | <MikeSmith> | WeirdAl: Larry is god |
| 18:10 | <MikeSmith> | he is deep into the matrix |
| 18:10 | <MikeSmith> | like Loki |
| 18:10 | <MikeSmith> | or the demiurge |
| 18:10 | <MikeSmith> | he is deep into the matrix |
| 18:10 | <TabAtkins_> | I know he's done good things. He's still crazy now. |
| 18:10 | <TabAtkins_> | I know he's done good things. He's still crazy now. |
| 18:14 | <MikeSmith> | TabAtkins_: I'm crazier |
| 18:14 | <MikeSmith> | I guarantee |
| 18:15 | <MikeSmith> | TabAtkins_: I'm crazier |
| 18:15 | <MikeSmith> | I guarantee |
| 18:16 | <TabAtkins_> | In a good way, though. |
| 18:17 | <TabAtkins_> | In a good way, though. |
| 18:34 | <MikeSmith> | Hixie: help me out man |
| 18:35 | <MikeSmith> | Hixie: help me out man |
| 18:35 | <MikeSmith> | the chairs are telling me they want stuff actually done before we can publish updated WDs |
| 18:35 | <MikeSmith> | the chairs are telling me they want stuff actually done before we can publish updated WDs |
| 18:35 | <MikeSmith> | specifically, |
| 18:35 | <MikeSmith> | http://intertwingly.net/tmp/wgstatus.html#editor |
| 18:36 | <MikeSmith> | specifically, |
| 18:36 | <MikeSmith> | http://intertwingly.net/tmp/wgstatus.html#editor |
| 18:36 | <MikeSmith> | the "Editor Queue" stufff |
| 18:36 | <MikeSmith> | the "Editor Queue" stufff |
| 18:36 | <MikeSmith> | so if you can actually make those changes in the W3 version you will be my hero for this week |
| 18:36 | <MikeSmith> | beyond TabAtkins_ |
| 18:37 | <MikeSmith> | so if you can actually make those changes in the W3 version you will be my hero for this week |
| 18:37 | <MikeSmith> | beyond TabAtkins_ |
| 18:41 | <Hixie> | MikeSmith: my timetable for the next few weeks is canvas, web intents, the start time thread on the whatwg list, sicking's readyState bugs, and then <dialog> and sandbox/CSP |
| 18:41 | <Hixie> | MikeSmith: my timetable for the next few weeks is canvas, web intents, the start time thread on the whatwg list, sicking's readyState bugs, and then <dialog> and sandbox/CSP |
| 18:45 | <MikeSmith> | Hixie: all I need for now is those WG decisions applied to the W3C versinos |
| 18:45 | <MikeSmith> | Hixie: all I need for now is those WG decisions applied to the W3C versinos |
| 18:45 | <MikeSmith> | so that we can publish on Thursay |
| 18:45 | <MikeSmith> | if you don't have time to apply them, I will, I gues |
| 18:46 | <MikeSmith> | so that we can publish on Thursay |
| 18:46 | <MikeSmith> | if you don't have time to apply them, I will, I gues |
| 18:46 | <MikeSmith> | but I would appreciate it if you tried |
| 18:46 | <MikeSmith> | but I would appreciate it if you tried |
| 18:46 | <MikeSmith> | so that i can reduce a bit the mountain of BS PITA that I have to deal with |
| 18:47 | <MikeSmith> | so that i can reduce a bit the mountain of BS PITA that I have to deal with |
| 18:47 | <Hixie> | MikeSmith: i'm adding your script to the pipeline as we speak, but the other two don't have simple diffs that need applying, they're both week-long efforts to try to work out exactly what should happen |
| 18:47 | <MikeSmith> | OK |
| 18:47 | <Hixie> | MikeSmith: e.g. the sandbox one needs basically a refactoring of the entire sandbox feature for CSP |
| 18:47 | <Hixie> | MikeSmith: i'm adding your script to the pipeline as we speak, but the other two don't have simple diffs that need applying, they're both week-long efforts to try to work out exactly what should happen |
| 18:47 | <MikeSmith> | OK |
| 18:47 | <Hixie> | MikeSmith: e.g. the sandbox one needs basically a refactoring of the entire sandbox feature for CSP |
| 18:47 | <MikeSmith> | I see |
| 18:47 | <Hixie> | MikeSmith: and the dialog one needs coordination with the fullscreen spec to work out how it'll work |
| 18:47 | <MikeSmith> | who submitted that CP? |
| 18:47 | <MikeSmith> | OK |
| 18:48 | <MikeSmith> | I see |
| 18:48 | <Hixie> | MikeSmith: and the dialog one needs coordination with the fullscreen spec to work out how it'll work |
| 18:48 | <MikeSmith> | who submitted that CP? |
| 18:48 | <MikeSmith> | OK |
| 18:48 | <Hixie> | MikeSmith: in both cases one could naively apply the exact diff the CP says to do, but that would just be a waste of everyone's time |
| 18:48 | <Hixie> | MikeSmith: in both cases one could naively apply the exact diff the CP says to do, but that would just be a waste of everyone's time |
| 18:48 | <Hixie> | MikeSmith: if anyone suggests you do that, i highly recommend explaining to them that they clearly care less about the web than about the appearance of progres and should maybe reconsider their life choices |
| 18:49 | <Hixie> | MikeSmith: if anyone suggests you do that, i highly recommend explaining to them that they clearly care less about the web than about the appearance of progres and should maybe reconsider their life choices |
| 18:49 | <MikeSmith> | yeah |
| 18:50 | <MikeSmith> | yeah |
| 18:50 | <Hixie> | (if the chairs actually wanted <dialog> in the spec quicker, they would have just let it happen without the escalation process, in which case hober and i would have put it in the spec sometime last year, when we had nothing more pressing to work on) |
| 18:51 | <Hixie> | (if the chairs actually wanted <dialog> in the spec quicker, they would have just let it happen without the escalation process, in which case hober and i would have put it in the spec sometime last year, when we had nothing more pressing to work on) |
| 18:56 | <MikeSmith> | Hixie: indee |
| 18:56 | <MikeSmith> | d |
| 18:57 | <MikeSmith> | Hixie: indee |
| 18:57 | <MikeSmith> | d |
| 18:57 | <MikeSmith> | the whole premature escalation thing I never did understand either |
| 18:57 | <MikeSmith> | the whole premature escalation thing I never did understand either |
| 18:57 | <MikeSmith> | anyway, we find ourselves at this poing |
| 18:57 | <MikeSmith> | as we have found ourselves before |
| 18:58 | <MikeSmith> | anyway, we find ourselves at this poing |
| 18:58 | <MikeSmith> | as we have found ourselves before |
| 18:58 | <Hixie> | i don't really see what is stopping them from just publishing |
| 18:58 | <Hixie> | i don't really see what is stopping them from just publishing |
| 18:58 | <Hixie> | i mean, there's nothing particularly special about these new features than the other new features i'm working on |
| 18:58 | <MikeSmith> | those 3 decisions, afaict |
| 18:58 | <Hixie> | i mean, why have they decided that they need those decisions applied but not, say, the canvas changes applied? |
| 18:59 | <Hixie> | i mean, there's nothing particularly special about these new features than the other new features i'm working on |
| 18:59 | <MikeSmith> | those 3 decisions, afaict |
| 18:59 | <Hixie> | i mean, why have they decided that they need those decisions applied but not, say, the canvas changes applied? |
| 18:59 | <Hixie> | i'd have thought the canvasregion hit testing changes were way more important/controversial in the wg |
| 18:59 | <Hixie> | i'd have thought the canvasregion hit testing changes were way more important/controversial in the wg |
| 19:01 | <MikeSmith> | Hixie: see the topic, ese |
| 19:01 | <MikeSmith> | Hixie: see the topic, ese |
| 19:01 | <Hixie> | it's one thing for the language to be irrational |
| 19:01 | <Hixie> | another for the people the w3c is putting forward as leaders to be irrational |
| 19:02 | <Hixie> | it's one thing for the language to be irrational |
| 19:02 | <Hixie> | another for the people the w3c is putting forward as leaders to be irrational |
| 19:02 | <MikeSmith> | leaders fail us |
| 19:02 | <MikeSmith> | everywhere |
| 19:03 | <MikeSmith> | leaders fail us |
| 19:03 | <MikeSmith> | everywhere |
| 19:03 | <MikeSmith> | we need to work around the "leaders" |
| 19:03 | <MikeSmith> | we need to work around the "leaders" |
| 19:04 | <Hixie> | i don't intend to work around anyone |
| 19:04 | <Hixie> | i don't intend to work around anyone |
| 19:04 | <MikeSmith> | yeah well I do I gues |
| 19:05 | <MikeSmith> | yeah well I do I gues |
| 19:05 | <MikeSmith> | I guess that's a difference between you and me |
| 19:05 | <MikeSmith> | I guess that's a difference between you and me |
| 19:05 | <annevk> | hober: I wasn't necessarily disagreeing, though it does seem somewhat weird to have event handler attributes |
| 19:05 | <annevk> | in the dictionary |
| 19:06 | <annevk> | hober: I wasn't necessarily disagreeing, though it does seem somewhat weird to have event handler attributes |
| 19:06 | <annevk> | in the dictionary |
| 19:06 | <MikeSmith> | Hixie: arguing with asshats on principle is fun for about 30 seconds |
| 19:06 | <MikeSmith> | te |
| 19:07 | <MikeSmith> | Hixie: arguing with asshats on principle is fun for about 30 seconds |
| 19:07 | <MikeSmith> | te |
| 19:07 | <MikeSmith> | then it gets boring an pointless |
| 19:07 | <MikeSmith> | then it gets boring an pointless |
| 19:08 | <Hixie> | you don't have to argue if someone asks you to do something dumb |
| 19:08 | <MikeSmith> | right |
| 19:08 | <Hixie> | that's what spam filters are for |
| 19:08 | <Hixie> | you don't have to argue if someone asks you to do something dumb |
| 19:08 | <MikeSmith> | right |
| 19:08 | <Hixie> | that's what spam filters are for |
| 19:09 | <MikeSmith> | in the mean time we actually want to get some WD published if we can |
| 19:09 | <MikeSmith> | in the mean time we actually want to get some WD published if we can |
| 19:10 | <Hixie> | so just publish what we have |
| 19:10 | <Hixie> | i really don't see the problem here |
| 19:10 | <Hixie> | so just publish what we have |
| 19:10 | <annevk> | MikeSmith: so html5-diff has validation errors? |
| 19:10 | <Hixie> | i really don't see the problem here |
| 19:10 | <annevk> | MikeSmith: so html5-diff has validation errors? |
| 19:10 | <MikeSmith> | annevk: dunno, maybe CSS non-erros |
| 19:10 | <Hixie> | MikeSmith: the whatwg manages to "publish a rec" every time i make a diff, why can't the w3c "publish a wd"? |
| 19:11 | <MikeSmith> | annevk: dunno, maybe CSS non-erros |
| 19:11 | <Hixie> | MikeSmith: the whatwg manages to "publish a rec" every time i make a diff, why can't the w3c "publish a wd"? |
| 19:11 | <MikeSmith> | fuck |
| 19:11 | <MikeSmith> | please |
| 19:11 | <MikeSmith> | fuck |
| 19:11 | <MikeSmith> | please |
| 19:11 | <MikeSmith> | Hixie: I can idiot that you ask me that? |
| 19:11 | <MikeSmith> | christ |
| 19:11 | <zewt> | parse error, redo from start |
| 19:12 | <MikeSmith> | Hixie: I can idiot that you ask me that? |
| 19:12 | <MikeSmith> | christ |
| 19:12 | <zewt> | parse error, redo from start |
| 19:12 | <MikeSmith> | * Am I can idiot that you ask me that |
| 19:12 | <MikeSmith> | * Am I can idiot that you ask me that |
| 19:12 | <annevk> | "You should add a 'type' attribute with a value of 'text/css' to the 'style' element" |
| 19:12 | <zewt> | not better :) |
| 19:12 | <annevk> | that sounds wrong |
| 19:13 | <annevk> | "You should add a 'type' attribute with a value of 'text/css' to the 'style' element" |
| 19:13 | <zewt> | not better :) |
| 19:13 | <annevk> | that sounds wrong |
| 19:13 | <MikeSmith> | zewt: god |
| 19:13 | <zewt> | uh? |
| 19:13 | <MikeSmith> | zewt: god |
| 19:13 | <zewt> | uh? |
| 19:13 | <MikeSmith> | * Am I an idiot that you ask me that |
| 19:13 | <MikeSmith> | fucking typewriters |
| 19:13 | <Hixie> | well i'm not really asking you, i'm asking whoever is telling you that you can't somehow |
| 19:14 | <MikeSmith> | * Am I an idiot that you ask me that |
| 19:14 | <MikeSmith> | fucking typewriters |
| 19:14 | <Hixie> | well i'm not really asking you, i'm asking whoever is telling you that you can't somehow |
| 19:14 | <MikeSmith> | Hixie: me |
| 19:14 | <MikeSmith> | I am asking you |
| 19:14 | <zewt> | if you're using a typewriter it may be time for an upgrade |
| 19:14 | <MikeSmith> | Hixie: me |
| 19:14 | <MikeSmith> | I am asking you |
| 19:14 | <zewt> | if you're using a typewriter it may be time for an upgrade |
| 19:14 | <MikeSmith> | so that we can publish on Thursday |
| 19:15 | <MikeSmith> | so that we can publish on Thursday |
| 19:15 | <MikeSmith> | if you can't make those changes by Thursday, then I guess we are up shit creek |
| 19:15 | <Hixie> | MikeSmith: oh you just want me to rerun the pipeline with the flags set for publication? i can do that, sure. i thought you were saying we were somehow gated on some random CPs. |
| 19:15 | <MikeSmith> | if you can't make those changes by Thursday, then I guess we are up shit creek |
| 19:15 | <Hixie> | MikeSmith: oh you just want me to rerun the pipeline with the flags set for publication? i can do that, sure. i thought you were saying we were somehow gated on some random CPs. |
| 19:15 | <MikeSmith> | yeah, re-run it |
| 19:15 | <MikeSmith> | I changed the boilerplate already |
| 19:16 | <MikeSmith> | yeah, re-run it |
| 19:16 | <MikeSmith> | I changed the boilerplate already |
| 19:16 | <Hixie> | k |
| 19:16 | <MikeSmith> | I leave it up to the chairs to deal with the aftermath |
| 19:16 | <Hixie> | k |
| 19:16 | <MikeSmith> | I leave it up to the chairs to deal with the aftermath |
| 19:16 | <Hixie> | what date should i use? |
| 19:16 | <MikeSmith> | which amounts to, they leave it up to me] |
| 19:16 | <MikeSmith> | 15 |
| 19:16 | <Hixie> | and which drafts |
| 19:16 | <MikeSmith> | html, md, canvas |
| 19:17 | <Hixie> | what date should i use? |
| 19:17 | <MikeSmith> | which amounts to, they leave it up to me] |
| 19:17 | <MikeSmith> | 15 |
| 19:17 | <Hixie> | and which drafts |
| 19:17 | <MikeSmith> | html, md, canvas |
| 19:17 | <MikeSmith> | I'm about ready to stab myself in the heart with a broken bottle here |
| 19:17 | <MikeSmith> | I'm about ready to stab myself in the heart with a broken bottle here |
| 19:17 | <gsnedders> | MikeSmith: emo. |
| 19:17 | <Hixie> | oh wait, i don't need to update the date, that's in the boilerplate now |
| 19:17 | <Hixie> | sweet |
| 19:18 | <gsnedders> | MikeSmith: emo. |
| 19:18 | <Hixie> | oh wait, i don't need to update the date, that's in the boilerplate now |
| 19:18 | <Hixie> | sweet |
| 19:18 | <MikeSmith> | gsnedders: dude I was em before there was a word for it |
| 19:18 | <MikeSmith> | gsnedders: dude I was em before there was a word for it |
| 19:18 | <MikeSmith> | and I will punk jackass that claims to have re-invented emo in my wake |
| 19:19 | <MikeSmith> | and I will punk jackass that claims to have re-invented emo in my wake |
| 19:20 | <TabAtkins_> | Yay, I can finally publish in HTML5! |
| 19:21 | <TabAtkins_> | Yay, I can finally publish in HTML5! |
| 19:21 | <annevk> | hmm |
| 19:21 | <annevk> | I wonder what dbaron just posted on twitter |
| 19:22 | <annevk> | hmm |
| 19:22 | <annevk> | I wonder what dbaron just posted on twitter |
| 19:22 | <TabAtkins_> | Hm. |
| 19:22 | <TabAtkins_> | Hm. |
| 19:22 | <TabAtkins_> | Don't want to try and decode it, given the possibility of wasted effort if twitter mangled it. |
| 19:22 | <annevk> | it's something about having 140 code units I reckon |
| 19:23 | <TabAtkins_> | Don't want to try and decode it, given the possibility of wasted effort if twitter mangled it. |
| 19:23 | <annevk> | it's something about having 140 code units I reckon |
| 19:23 | <gsnedders> | MikeSmith: Your kisses kill me a little inside. |
| 19:23 | <gsnedders> | MikeSmith: Your kisses kill me a little inside. |
| 19:23 | <TabAtkins_> | Likely. I'll bet it's using one of the alternate roman alphabets in the multibyte sections. |
| 19:23 | <MikeSmith> | gsnedders: wonderful phrase |
| 19:24 | <TabAtkins_> | Likely. I'll bet it's using one of the alternate roman alphabets in the multibyte sections. |
| 19:24 | <MikeSmith> | gsnedders: wonderful phrase |
| 19:25 | <MikeSmith> | TabAtkins_: please work with closely with Elika to create another 30 CSSSS specs |
| 19:25 | <TabAtkins_> | MikeSmith: Already on it. |
| 19:25 | <MikeSmith> | TabAtkins_: please work with closely with Elika to create another 30 CSSSS specs |
| 19:25 | <TabAtkins_> | MikeSmith: Already on it. |
| 19:25 | <MikeSmith> | heh |
| 19:25 | <annevk> | MikeSmith: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16347 |
| 19:26 | <MikeSmith> | heh |
| 19:26 | <annevk> | MikeSmith: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16347 |
| 19:27 | <MikeSmith> | annevk: ありがとうございます |
| 19:27 | <MikeSmith> | annevk: ありがとうございます |
| 19:27 | <annevk> | 問題ない |
| 19:27 | <TabAtkins_> | What the hell is that "XSL or XQuery WG" checkbox doing floating over there? |
| 19:27 | <MikeSmith> | heh |
| 19:28 | <annevk> | 問題ない |
| 19:28 | <TabAtkins_> | What the hell is that "XSL or XQuery WG" checkbox doing floating over there? |
| 19:28 | <aklein> | Hixie: hi there. random question about the "form" attribute: if a form-associated element is not in the document tree, should it still be associated with a form if it has a "form" attribute matching the ID of a <form> that _is_ in the document? |
| 19:28 | <MikeSmith> | heh |
| 19:28 | <aklein> | Hixie: hi there. random question about the "form" attribute: if a form-associated element is not in the document tree, should it still be associated with a form if it has a "form" attribute matching the ID of a <form> that _is_ in the document? |
| 19:28 | <aklein> | (poking around at WebKit's incomplete implementation) |
| 19:28 | <aklein> | (poking around at WebKit's incomplete implementation) |
| 19:28 | <MikeSmith> | TabAtkins_: that is to remind you about how important X-*shite is |
| 19:28 | <aklein> | from my reading it seems the form attribute basically overrides the tree-based form-association rules |
| 19:29 | <MikeSmith> | TabAtkins_: that is to remind you about how important X-*shite is |
| 19:29 | <aklein> | from my reading it seems the form attribute basically overrides the tree-based form-association rules |
| 19:29 | <TabAtkins_> | MikeSmith: Should I just check it on every bug? I've already started doing so. |
| 19:29 | <TabAtkins_> | MikeSmith: Should I just check it on every bug? I've already started doing so. |
| 19:29 | <MikeSmith> | heh |
| 19:29 | <annevk> | the stuff from dbaron is in the Shavian Alphabet apparently? |
| 19:29 | <annevk> | http://www.unicode.org/standard/translations/shavian.html |
| 19:30 | <MikeSmith> | heh |
| 19:30 | <annevk> | the stuff from dbaron is in the Shavian Alphabet apparently? |
| 19:30 | <annevk> | http://www.unicode.org/standard/translations/shavian.html |
| 19:30 | <Hixie> | aklein: looking... |
| 19:30 | <Hixie> | aklein: looking... |
| 19:30 | <MikeSmith> | TabAtkins_: maybe I can change the config. I dunno. configuring bugzillla dpresses me |
| 19:30 | <AryehGregor> | . . . wow, backface-visibility interop is much worse than I thought. |
| 19:31 | <MikeSmith> | TabAtkins_: maybe I can change the config. I dunno. configuring bugzillla dpresses me |
| 19:31 | <AryehGregor> | . . . wow, backface-visibility interop is much worse than I thought. |
| 19:31 | <AryehGregor> | I need lots more tests for this. |
| 19:31 | <AryehGregor> | I need lots more tests for this. |
| 19:31 | <TabAtkins_> | MikeSmith: I'm just wondering why those WGs have the ability to mark bugs as WG-private anyway. It's bizarre. |
| 19:32 | <TabAtkins_> | MikeSmith: I'm just wondering why those WGs have the ability to mark bugs as WG-private anyway. It's bizarre. |
| 19:32 | <Hixie> | aklein: yeah, looks like the spec says that it should be associated even if the control isn't in the same subtree as the form element |
| 19:32 | <Hixie> | aklein: the form element has to be in the document, though |
| 19:32 | <Hixie> | aklein: yeah, looks like the spec says that it should be associated even if the control isn't in the same subtree as the form element |
| 19:32 | <Hixie> | aklein: the form element has to be in the document, though |
| 19:33 | <annevk> | so you can submit controls not part of the DOM |
| 19:33 | <Hixie> | ok canvas now supports ellipses |
| 19:33 | <annevk> | that's kind of weird |
| 19:33 | <annevk> | so you can submit controls not part of the DOM |
| 19:33 | <Hixie> | ok canvas now supports ellipses |
| 19:33 | <annevk> | that's kind of weird |
| 19:33 | <Hixie> | MikeSmith: i am checking in the wds with WD livery |
| 19:33 | <Hixie> | s/wds/docs/ |
| 19:33 | <MikeSmith> | ok |
| 19:34 | <Hixie> | MikeSmith: i am checking in the wds with WD livery |
| 19:34 | <Hixie> | s/wds/docs/ |
| 19:34 | <MikeSmith> | ok |
| 19:34 | <MikeSmith> | TabAtkins_: eh? which groups? |
| 19:34 | <MikeSmith> | TabAtkins_: eh? which groups? |
| 19:35 | <MikeSmith> | TabAtkins_: if you mean the "XSL or XQuery WG" bugzilla thing I have zero insight |
| 19:36 | <MikeSmith> | TabAtkins_: if you mean the "XSL or XQuery WG" bugzilla thing I have zero insight |
| 19:36 | <aklein> | Hixie: thanks, that's what I got from my reading. WebKit sometimes lets such associations take place, Firefox doesn't seem to. |
| 19:36 | <rniwa> | what's a good irc channel for regions discussion? |
| 19:36 | <TabAtkins_> | MikeSmith: Yeah, that. It's a new thing, so it's weird. |
| 19:36 | <TabAtkins_> | rniwa: Here, or w3.org/#css |
| 19:36 | <rniwa> | what's a good irc channel for regions discussion? |
| 19:36 | <TabAtkins_> | MikeSmith: Yeah, that. It's a new thing, so it's weird. |
| 19:36 | <TabAtkins_> | rniwa: Here, or w3.org/#css |
| 19:36 | <aklein> | (it's not clear the WebKit impl meant to let this take place) |
| 19:36 | <MikeSmith> | OK |
| 19:36 | <rniwa> | TabAtkins_: okay. i guess i'll start here since i'm already here |
| 19:36 | <TabAtkins_> | MikeSmith: I'm pretty sure that checkbox wasn't in place a week ago. |
| 19:36 | <rniwa> | TabAtkins_, annevk: so we've had some more discussions about regions node list |
| 19:37 | <aklein> | (it's not clear the WebKit impl meant to let this take place) |
| 19:37 | <MikeSmith> | OK |
| 19:37 | <rniwa> | TabAtkins_: okay. i guess i'll start here since i'm already here |
| 19:37 | <TabAtkins_> | MikeSmith: I'm pretty sure that checkbox wasn't in place a week ago. |
| 19:37 | <rniwa> | TabAtkins_, annevk: so we've had some more discussions about regions node list |
| 19:37 | <rniwa> | and we're rolling out webkit's implementation for now since it's not implemented correctly |
| 19:37 | <MikeSmith> | TabAtkins_: hai |
| 19:37 | <rniwa> | and we're rolling out webkit's implementation for now since it's not implemented correctly |
| 19:37 | <MikeSmith> | TabAtkins_: hai |
| 19:37 | <rniwa> | but dhyatt pointed out a point that in the future, regions node list can have css generated nodes as well |
| 19:37 | <TabAtkins_> | rniwa: You mean that api that lets you get the boxes that a region spans? |
| 19:37 | <rniwa> | TabAtkins_: yeah |
| 19:37 | <rniwa> | TabAtkins_: or rather "nodes" |
| 19:37 | <TabAtkins_> | Yeah, Hyatt's right. |
| 19:38 | <rniwa> | but dhyatt pointed out a point that in the future, regions node list can have css generated nodes as well |
| 19:38 | <TabAtkins_> | rniwa: You mean that api that lets you get the boxes that a region spans? |
| 19:38 | <rniwa> | TabAtkins_: yeah |
| 19:38 | <rniwa> | TabAtkins_: or rather "nodes" |
| 19:38 | <TabAtkins_> | Yeah, Hyatt's right. |
| 19:38 | <rniwa> | TabAtkins_: so we need some mechanism to represent css generated nodes |
| 19:38 | <annevk> | in general, adding new CSSOM stuff without having fixed the underlying model is scary imo |
| 19:38 | <TabAtkins_> | Heh, pinging alex russell. |
| 19:38 | <rniwa> | TabAtkins_: so we need some mechanism to represent css generated nodes |
| 19:38 | <annevk> | in general, adding new CSSOM stuff without having fixed the underlying model is scary imo |
| 19:38 | <TabAtkins_> | Heh, pinging alex russell. |
| 19:38 | <rniwa> | TabAtkins_: it can be of type Node since it's not a real node |
| 19:38 | <rniwa> | annevk: I agree. |
| 19:38 | <TabAtkins_> | annevk: Probably agree. |
| 19:39 | <rniwa> | TabAtkins_: it can be of type Node since it's not a real node |
| 19:39 | <rniwa> | annevk: I agree. |
| 19:39 | <rniwa> | TabAtkins_, annevk: what would this pseudo-node look like? |
| 19:39 | <TabAtkins_> | annevk: Probably agree. |
| 19:39 | <rniwa> | TabAtkins_, annevk: what would this pseudo-node look like? |
| 19:39 | <annevk> | we have not figured out how CSSOM should look, yet CSSMatrix is being added somewhat brokenly, now regions, there's stuff for variables... |
| 19:39 | <TabAtkins_> | rniwa: Dunno! |
| 19:39 | <annevk> | we have not figured out how CSSOM should look, yet CSSMatrix is being added somewhat brokenly, now regions, there's stuff for variables... |
| 19:39 | <TabAtkins_> | rniwa: Dunno! |
| 19:39 | <rniwa> | annevk: :( |
| 19:39 | <TabAtkins_> | annevk: At least for vars, it's just some stuff on the CSSStyleDeclaration. |
| 19:39 | <annevk> | rniwa: wouldn't CSS just generate boxes? |
| 19:39 | <rniwa> | annevk: yeah |
| 19:39 | <rniwa> | annevk: but how do you prefer to span:before { flow-from: "my-flow"; } |
| 19:40 | <rniwa> | annevk: :( |
| 19:40 | <TabAtkins_> | annevk: At least for vars, it's just some stuff on the CSSStyleDeclaration. |
| 19:40 | <annevk> | rniwa: wouldn't CSS just generate boxes? |
| 19:40 | <rniwa> | annevk: yeah |
| 19:40 | <rniwa> | annevk: but how do you prefer to span:before { flow-from: "my-flow"; } |
| 19:40 | <rniwa> | annevk: it's not a real node |
| 19:40 | <rniwa> | annevk: it's a pseudo-node but it's part of the flow nonetheless |
| 19:40 | <rniwa> | annevk: it's a pseudo-node but it's part of the flow nonetheless |
| 19:40 | <rniwa> | annevk: so if you're getting the list of nodes that belong to the same flow |
| 19:40 | <rniwa> | then it's got to be there |
| 19:40 | <annevk> | maybe introduce CSSNode? |
| 19:40 | <TabAtkins_> | rniwa: You'll have to reify CSS pseudo-elements to do this correctly. |
| 19:41 | <rniwa> | annevk: so if you're getting the list of nodes that belong to the same flow |
| 19:41 | <rniwa> | then it's got to be there |
| 19:41 | <annevk> | maybe introduce CSSNode? |
| 19:41 | <TabAtkins_> | rniwa: You'll have to reify CSS pseudo-elements to do this correctly. |
| 19:41 | <annevk> | making it inherit from Node though seems wrong |
| 19:41 | <annevk> | making it inherit from Node though seems wrong |
| 19:41 | <rniwa> | TabAtkins_: right. |
| 19:41 | <TabAtkins_> | (Which I'm totally cool with.) |
| 19:41 | <annevk> | so maybe it should just be CSSBox and you mix it in the list |
| 19:41 | <rniwa> | TabAtkins_: right. |
| 19:41 | <rniwa> | annevk: definitely not > inherit from Node |
| 19:41 | <TabAtkins_> | (Which I'm totally cool with.) |
| 19:41 | <TabAtkins_> | (If we can do it in a performant way.) |
| 19:41 | <annevk> | so maybe it should just be CSSBox and you mix it in the list |
| 19:41 | <rniwa> | annevk: definitely not > inherit from Node |
| 19:41 | <TabAtkins_> | (If we can do it in a performant way.) |
| 19:41 | <rniwa> | annevk: yeah... |
| 19:41 | <annevk> | you can have (CSSBox or Node)[] |
| 19:41 | <rniwa> | annevk: "Box" is kind of confusing though |
| 19:41 | <rniwa> | annevk: because it's an inline / block objects |
| 19:41 | <TabAtkins_> | rniwa: I think you were in the room months ago when we were discussing reifying pseudoelements in some way related to the shadow dom. |
| 19:41 | <rniwa> | annevk: not really line boxes |
| 19:42 | <rniwa> | annevk: yeah... |
| 19:42 | <annevk> | you can have (CSSBox or Node)[] |
| 19:42 | <rniwa> | annevk: "Box" is kind of confusing though |
| 19:42 | <rniwa> | annevk: because it's an inline / block objects |
| 19:42 | <rniwa> | TabAtkins_: was I? |
| 19:42 | <TabAtkins_> | rniwa: I think you were in the room months ago when we were discussing reifying pseudoelements in some way related to the shadow dom. |
| 19:42 | <rniwa> | annevk: not really line boxes |
| 19:42 | <rniwa> | TabAtkins_: oh yeah |
| 19:42 | <rniwa> | TabAtkins_: was I? |
| 19:42 | <rniwa> | TabAtkins_: oh yeah |
| 19:42 | <rniwa> | TabAtkins_: decorator stuff |
| 19:42 | <annevk> | from a spec perspective they're all boxes |
| 19:42 | <annevk> | from a spec perspective they're all boxes |
| 19:42 | <rniwa> | TabAtkins_: but I think decorator approach is an overkill for this |
| 19:42 | <annevk> | block-level, inline-level, line-level boxes |
| 19:42 | <rniwa> | TabAtkins_: because that'll make them real nodes |
| 19:42 | <rniwa> | TabAtkins_: but I think decorator approach is an overkill for this |
| 19:42 | <annevk> | block-level, inline-level, line-level boxes |
| 19:42 | <rniwa> | TabAtkins_: because that'll make them real nodes |
| 19:42 | <TabAtkins_> | rniwa, annevk: "box" isn't the right term, anyway. That's a level too far down. You want the notion that CSS has of "elements" after it's doctored the tree. |
| 19:42 | <rniwa> | TabAtkins_: yeah |
| 19:42 | <TabAtkins_> | But before converting the element-tree to the box-tree. |
| 19:42 | <rniwa> | TabAtkins_: for that, I like CSSElement or CSSNode |
| 19:42 | <rniwa> | TabAtkins_: or PseudoNode |
| 19:43 | <TabAtkins_> | rniwa, annevk: "box" isn't the right term, anyway. That's a level too far down. You want the notion that CSS has of "elements" after it's doctored the tree. |
| 19:43 | <rniwa> | TabAtkins_: yeah |
| 19:43 | <TabAtkins_> | But before converting the element-tree to the box-tree. |
| 19:43 | <rniwa> | TabAtkins_: for that, I like CSSElement or CSSNode |
| 19:43 | <rniwa> | TabAtkins_: or PseudoNode |
| 19:43 | <rniwa> | i like the third one least since nobody can spell pseudo correctly :P |
| 19:43 | <annevk> | PseudoElement then |
| 19:43 | <rniwa> | i like the third one least since nobody can spell pseudo correctly :P |
| 19:43 | <annevk> | PseudoElement then |
| 19:43 | <rniwa> | annevk: LOL |
| 19:43 | <TabAtkins_> | I'd want to spend some time hashing this out publicly, but something like that sounds interesting. |
| 19:43 | <rniwa> | TabAtkins_: yeah |
| 19:43 | <TabAtkins_> | ::element, obviously. |
| 19:43 | <rniwa> | TabAtkins_: was there cssom mailing list? |
| 19:43 | <TabAtkins_> | window['::element'](foo) |
| 19:43 | <TabAtkins_> | rniwa: www-style |
| 19:43 | <rniwa> | TabAtkins_: oh man... :( |
| 19:44 | <rniwa> | annevk: LOL |
| 19:44 | <TabAtkins_> | I'd want to spend some time hashing this out publicly, but something like that sounds interesting. |
| 19:44 | <rniwa> | TabAtkins_: yeah |
| 19:44 | <TabAtkins_> | ::element, obviously. |
| 19:44 | <rniwa> | TabAtkins_: was there cssom mailing list? |
| 19:44 | <TabAtkins_> | window['::element'](foo) |
| 19:44 | <annevk> | rniwa: uhuh |
| 19:44 | <TabAtkins_> | rniwa: www-style |
| 19:44 | <rniwa> | TabAtkins_: oh man... :( |
| 19:44 | <rniwa> | TabAtkins_: i don't wanna subscribe to www-style |
| 19:44 | <annevk> | rniwa: uhuh |
| 19:44 | <rniwa> | TabAtkins_: i don't wanna subscribe to www-style |
| 19:44 | <Hixie> | aklein: file bugs :-) we can also change the spec if the browser vendors think this is bad, it wasn't exactly intentional, it just fell out of how i specced it |
| 19:44 | <TabAtkins_> | rniwa: Sorry. |
| 19:44 | <Hixie> | aklein: file bugs :-) we can also change the spec if the browser vendors think this is bad, it wasn't exactly intentional, it just fell out of how i specced it |
| 19:44 | <TabAtkins_> | rniwa: Sorry. |
| 19:45 | <rniwa> | TabAtkins_, annevk: CSSElement would do. |
| 19:45 | <rniwa> | TabAtkins_, annevk: CSSElement would do. |
| 19:45 | <TabAtkins_> | Yeah, that works for me. |
| 19:45 | <TabAtkins_> | Yeah, that works for me. |
| 19:46 | <Hixie> | anyone know what the url is for the absolute latest svg spec content? (draft/ed content is fine) |
| 19:46 | <TabAtkins_> | Hixie: Generally, you want SVG Tiny 1.2 for definitions or stuff. |
| 19:46 | <annevk> | TabAtkins_: I didn't know CSS had something between "tree" and "box tree" |
| 19:47 | <TabAtkins_> | Hixie: Generally, you want SVG Tiny 1.2 for definitions or stuff. |
| 19:47 | <annevk> | TabAtkins_: I didn't know CSS had something between "tree" and "box tree" |
| 19:47 | <annevk> | TabAtkins_: where is that defined? |
| 19:47 | <Hixie> | TabAtkins_: but 1.1 for dom stuff? |
| 19:47 | <annevk> | TabAtkins_: where is that defined? |
| 19:47 | <TabAtkins_> | annevk: It's not well-defined, because no one's written Box 3. |
| 19:47 | <Hixie> | TabAtkins_: svg 1.1 has a more elaborate d="" syntax than 1.2 T |
| 19:47 | <TabAtkins_> | Hixie: Yes. |
| 19:47 | <Hixie> | TabAtkins_: but 1.1 for dom stuff? |
| 19:47 | <TabAtkins_> | annevk: It's not well-defined, because no one's written Box 3. |
| 19:47 | <Hixie> | TabAtkins_: svg 1.1 has a more elaborate d="" syntax than 1.2 T |
| 19:47 | <TabAtkins_> | Hixie: Yes. |
| 19:47 | <annevk> | hmm |
| 19:47 | <Hixie> | TabAtkins_: any idea which is the "right" one? |
| 19:47 | <TabAtkins_> | Hixie: Ask shepazu or heycam. |
| 19:48 | <annevk> | hmm |
| 19:48 | <Hixie> | TabAtkins_: any idea which is the "right" one? |
| 19:48 | <TabAtkins_> | Hixie: Ask shepazu or heycam. |
| 19:48 | <Hixie> | (what i was really hoping for was an svg 2 ED or something) |
| 19:48 | <TabAtkins_> | annevk: You've got what the host-language reports, which is used for Selectors. CSS decorates it with pseudos to form the element-tree. |
| 19:48 | <Hixie> | (what i was really hoping for was an svg 2 ED or something) |
| 19:48 | <TabAtkins_> | annevk: You've got what the host-language reports, which is used for Selectors. CSS decorates it with pseudos to form the element-tree. |
| 19:48 | <TabAtkins_> | Hixie: There's an SVG2 in the hg repo, but it's not usable yet for good stuff, I think. |
| 19:49 | <TabAtkins_> | Hixie: There's an SVG2 in the hg repo, but it's not usable yet for good stuff, I think. |
| 19:49 | <annevk> | isn't pseudo + anonymous box stuff all happening at the same time? |
| 19:49 | <TabAtkins_> | Nope. |
| 19:49 | <annevk> | isn't pseudo + anonymous box stuff all happening at the same time? |
| 19:49 | <TabAtkins_> | Nope. |
| 19:49 | <TabAtkins_> | For example, pseudos can affects the table-fixup stuff. |
| 19:50 | <TabAtkins_> | For example, pseudos can affects the table-fixup stuff. |
| 19:50 | <TabAtkins_> | There's no reasonable way to define it simultaneously, I think. But everything works great if you define it happening before box-tree construction. |
| 19:50 | <annevk> | I guess they are input to the box generation |
| 19:50 | <TabAtkins_> | Yeah, exactly. |
| 19:50 | <TabAtkins_> | There's no reasonable way to define it simultaneously, I think. But everything works great if you define it happening before box-tree construction. |
| 19:50 | <annevk> | I guess they are input to the box generation |
| 19:50 | <TabAtkins_> | Yeah, exactly. |
| 19:50 | <annevk> | but so is display:block |
| 19:50 | <TabAtkins_> | Yes, display:block controls how an element generates a box. |
| 19:50 | <annevk> | and I'm not sure there's much of a difference there |
| 19:51 | <annevk> | but so is display:block |
| 19:51 | <TabAtkins_> | Yes, display:block controls how an element generates a box. |
| 19:51 | <annevk> | and I'm not sure there's much of a difference there |
| 19:51 | <TabAtkins_> | While a pseudo needs to be an element so it can *have* display:block on it. |
| 19:51 | <annevk> | I mean sure tr might have ::before |
| 19:51 | <TabAtkins_> | And then generate a box appropriately. |
| 19:51 | <annevk> | if it also has display:inline; thinks are going to be different too |
| 19:51 | <TabAtkins_> | While a pseudo needs to be an element so it can *have* display:block on it. |
| 19:51 | <annevk> | I mean sure tr might have ::before |
| 19:51 | <TabAtkins_> | And then generate a box appropriately. |
| 19:51 | <annevk> | if it also has display:inline; thinks are going to be different too |
| 19:51 | <TabAtkins_> | annevk: I can just assure you that assuming that pseudos are part of the element-tree makes literally everything related to box generation easier. |
| 19:52 | <TabAtkins_> | annevk: I can just assure you that assuming that pseudos are part of the element-tree makes literally everything related to box generation easier. |
| 19:52 | <Hixie> | TabAtkins_: k... |
| 19:52 | <Hixie> | TabAtkins_: k... |
| 19:53 | <TabAtkins_> | annevk: Otherwise you have to insert tons of special-cases everywhere and use horrible guarded language everywhere and will still, inevitably, fuck up corner-cases. |
| 19:53 | <TabAtkins_> | annevk: Otherwise you have to insert tons of special-cases everywhere and use horrible guarded language everywhere and will still, inevitably, fuck up corner-cases. |
| 19:53 | <annevk> | that sounds like how the CSS specs work |
| 19:53 | <TabAtkins_> | Boo |
| 19:54 | <annevk> | that sounds like how the CSS specs work |
| 19:54 | <TabAtkins_> | Boo |
| 19:54 | <annevk> | look no further than chapter 10 of CSS 2.1 |
| 19:54 | <annevk> | look no further than chapter 10 of CSS 2.1 |
| 19:58 | <annevk> | so the dbaron thing again... |
| 19:58 | <annevk> | it's more than a 140 16-bit code units |
| 19:59 | <annevk> | so the dbaron thing again... |
| 19:59 | <annevk> | it's more than a 140 16-bit code units |
| 19:59 | <annevk> | it's 193, which means Twitter counts Unicode characters? |
| 20:00 | <annevk> | it's 193, which means Twitter counts Unicode characters? |
| 20:00 | <gsnedders> | annevk: Correct. |
| 20:00 | <gsnedders> | annevk: They changed about a year ago. |
| 20:01 | <gsnedders> | annevk: Correct. |
| 20:01 | <gsnedders> | annevk: They changed about a year ago. |
| 20:01 | <gsnedders> | annevk: IIRC, it's graphemes they count provided the code points are defined. |
| 20:01 | <zewt> | now if only they'd change to, say, not limit messages to so small a length that it inhibits communication |
| 20:01 | <gsnedders> | annevk: IIRC, it's graphemes they count provided the code points are defined. |
| 20:01 | <zewt> | now if only they'd change to, say, not limit messages to so small a length that it inhibits communication |
| 20:02 | <zewt> | it's entirely silly that you can fit like twice the content on twitter in japanese than english, heh |
| 20:02 | <zewt> | it's entirely silly that you can fit like twice the content on twitter in japanese than english, heh |
| 20:05 | <annevk> | gsnedders: they count code points after normalizing the text to NFC according to https://dev.twitter.com/docs/counting-characters |
| 20:05 | <annevk> | gsnedders: they count code points after normalizing the text to NFC according to https://dev.twitter.com/docs/counting-characters |
| 20:56 | <matjas> | http://whatwg.org/html/infrastructure.html#conformance-checkers → any examples of “criteria that cannot be expressed by a DTD, but can still be checked by a machine”, and/or “criteria that can only be checked by a human”? |
| 20:57 | <matjas> | http://whatwg.org/html/infrastructure.html#conformance-checkers → any examples of “criteria that cannot be expressed by a DTD, but can still be checked by a machine”, and/or “criteria that can only be checked by a human”? |
| 20:58 | <TabAtkins_> | There are several examples of the former in the validator. |
| 20:58 | <TabAtkins_> | There are several examples of the former in the validator. |
| 20:58 | <TabAtkins_> | The latter is things like @alt conformance. |
| 20:59 | <TabAtkins_> | The latter is things like @alt conformance. |
| 20:59 | <matjas> | TabAtkins_: are those listed somewhere? |
| 20:59 | <TabAtkins_> | I doubt it. Nobody really cares. ^_^ |
| 20:59 | <matjas> | TabAtkins_: are those listed somewhere? |
| 20:59 | <TabAtkins_> | I doubt it. Nobody really cares. ^_^ |
| 20:59 | <matjas> | “There are several examples of the former in the validator.” → could you please name one then? I can’t think of any :) |
| 21:00 | <matjas> | “There are several examples of the former in the validator.” → could you please name one then? I can’t think of any :) |
| 21:00 | <TabAtkins_> | I dunno. Ask the validator folks like hsivonen or MikeSmith |
| 21:00 | <TabAtkins_> | I dunno. Ask the validator folks like hsivonen or MikeSmith |
| 21:00 | <matjas> | consider yourselves pinged, fellas. |
| 21:01 | <matjas> | consider yourselves pinged, fellas. |
| 21:09 | <TabAtkins_> | Lolwut. A few months of Process (that was largely built for the a11y people) is harming longdesc? |
| 21:09 | <TabAtkins_> | What about the 10+ years of authors ignoring or misusing it? |
| 21:09 | <TabAtkins_> | Lolwut. A few months of Process (that was largely built for the a11y people) is harming longdesc? |
| 21:09 | <TabAtkins_> | What about the 10+ years of authors ignoring or misusing it? |
| 21:14 | <Philip`> | matjas: Table constraints are one major machine-checkable area, if I remember correctly |
| 21:15 | <Philip`> | matjas: Table constraints are one major machine-checkable area, if I remember correctly |
| 21:15 | <Philip`> | matjas: e.g. verifying that there are no overlapping cells (in the presence of colspan and rowspan) |
| 21:16 | <Philip`> | matjas: e.g. verifying that there are no overlapping cells (in the presence of colspan and rowspan) |
| 21:21 | <AryehGregor> | What does CSS specify for how an image is supposed to be transformed when it has an explicit height/width? |
| 21:22 | <AryehGregor> | What does CSS specify for how an image is supposed to be transformed when it has an explicit height/width? |
| 21:22 | <AryehGregor> | It seems like a PNG is stretched or squished without regard to aspect ratio, if both are specified, but an SVG always preserves its aspect ratio and gets letterboxed. |
| 21:22 | <AryehGregor> | In an <img>. |
| 21:22 | <AryehGregor> | That seems very confusing. |
| 21:22 | <TabAtkins_> | It doesn't, very specifically. How an image draws itself into the rectangle that CSS tells it to is up tot he iamge format. |
| 21:22 | <AryehGregor> | That doesn't seem desirable. |
| 21:23 | <AryehGregor> | It seems like a PNG is stretched or squished without regard to aspect ratio, if both are specified, but an SVG always preserves its aspect ratio and gets letterboxed. |
| 21:23 | <TabAtkins_> | Rasters are stretched, SVG (in the absence of bugs) depends on the values fo the viewport stuff on the root. |
| 21:23 | <AryehGregor> | In an <img>. |
| 21:23 | <AryehGregor> | That seems very confusing. |
| 21:23 | <TabAtkins_> | It doesn't, very specifically. How an image draws itself into the rectangle that CSS tells it to is up tot he iamge format. |
| 21:23 | <AryehGregor> | That doesn't seem desirable. |
| 21:23 | <TabAtkins_> | Rasters are stretched, SVG (in the absence of bugs) depends on the values fo the viewport stuff on the root. |
| 21:23 | <AryehGregor> | Hmm. |
| 21:23 | <AryehGregor> | Interesting. |
| 21:23 | <AryehGregor> | Hmm. |
| 21:23 | <TabAtkins_> | It's quite desirable, given things like SVG that want to specify their scaling behavior. |
| 21:23 | <AryehGregor> | Interesting. |
| 21:23 | <TabAtkins_> | It's quite desirable, given things like SVG that want to specify their scaling behavior. |
| 21:24 | <AryehGregor> | http://www.w3.org/TR/SVG/coords.html#PreserveAspectRatioAttribute |
| 21:24 | <AryehGregor> | http://www.w3.org/TR/SVG/coords.html#PreserveAspectRatioAttribute |
| 21:24 | <TabAtkins_> | Yup. |
| 21:25 | <TabAtkins_> | Yup. |
| 21:25 | AryehGregor | doesn't see what the default is |
| 21:25 | AryehGregor | doesn't see what the default is |
| 21:26 | <TabAtkins_> | Check the definition for <svg>. |
| 21:26 | <TabAtkins_> | It's "xMidYMid meet". |
| 21:26 | <TabAtkins_> | Check the definition for <svg>. |
| 21:26 | <TabAtkins_> | It's "xMidYMid meet". |
| 21:26 | <TabAtkins_> | Also: omigod worst attribute value names ever. |
| 21:26 | <TabAtkins_> | EVER |
| 21:26 | <TabAtkins_> | Differing capitalization for x and y asldfkja;sdlkf |
| 21:27 | <TabAtkins_> | Also: omigod worst attribute value names ever. |
| 21:27 | <TabAtkins_> | EVER |
| 21:27 | <TabAtkins_> | Differing capitalization for x and y asldfkja;sdlkf |
| 21:27 | <TabAtkins_> | This is one of those things that should *really* change in SVG2 to match the CSS convention (which was established *after* SVG did its stuff, so its understandable why it doesn't currently match). |
| 21:28 | <TabAtkins_> | This is one of those things that should *really* change in SVG2 to match the CSS convention (which was established *after* SVG did its stuff, so its understandable why it doesn't currently match). |
| 21:28 | <AryehGregor> | Browsers seem to not implement this right. Sigh. |
| 21:28 | <TabAtkins_> | Unsurprising. |
| 21:28 | <AryehGregor> | Browsers seem to not implement this right. Sigh. |
| 21:28 | <TabAtkins_> | Unsurprising. |
| 21:28 | <TabAtkins_> | I know that Chrome does pretty badly. |
| 21:29 | <TabAtkins_> | I know that Chrome does pretty badly. |
| 21:45 | <Hixie> | should path.addPathData(svgPathData) continue the current subpath if any, or always start a new one? |
| 21:46 | <Hixie> | should path.addPathData(svgPathData) continue the current subpath if any, or always start a new one? |
| 21:47 | <TabAtkins_> | Hm. |
| 21:47 | <TabAtkins_> | Hm. |
| 21:48 | <TabAtkins_> | It would be useful to be able to interrupt the subpath construction and continue it, so you can insert a conditional without repeating the prelude or having to store it in a var for later concat. |
| 21:48 | <TabAtkins_> | It would be useful to be able to interrupt the subpath construction and continue it, so you can insert a conditional without repeating the prelude or having to store it in a var for later concat. |
| 21:48 | <TabAtkins_> | But SVG always starts with a fresh subpath (because it doesn't have the concept of extending one). |
| 21:49 | <TabAtkins_> | But SVG always starts with a fresh subpath (because it doesn't have the concept of extending one). |
| 21:49 | <TabAtkins_> | I think it should always start a new one. |
| 21:49 | <TabAtkins_> | I think it should always start a new one. |
| 21:49 | <Hixie> | hm, good point about stringing things together with if statements |
| 21:50 | <Hixie> | hm, good point about stringing things together with if statements |
| 21:50 | <TabAtkins_> | You can always just repeat the last point yourself, though. |
| 21:50 | <TabAtkins_> | You can always just repeat the last point yourself, though. |
| 21:51 | <Hixie> | but that would create a new subpath |
| 21:52 | <Hixie> | but that would create a new subpath |
| 21:52 | <Hixie> | so it would be quite different |
| 21:52 | <TabAtkins_> | Another possibility is extending the path syntax with a command (vaguely similar to z) that forces continuation from the previous subpath. |
| 21:52 | <TabAtkins_> | Oh yeah, stroking has different behavior. |
| 21:52 | <Hixie> | fill, too |
| 21:52 | <Hixie> | so it would be quite different |
| 21:52 | <TabAtkins_> | Hm. |
| 21:52 | <TabAtkins_> | Another possibility is extending the path syntax with a command (vaguely similar to z) that forces continuation from the previous subpath. |
| 21:52 | <TabAtkins_> | Oh yeah, stroking has different behavior. |
| 21:52 | <Hixie> | fill, too |
| 21:52 | <TabAtkins_> | Hm. |
| 21:52 | <Hixie> | and clip |
| 21:52 | <Hixie> | the three things you can do :-) |
| 21:52 | <TabAtkins_> | Heh. |
| 21:52 | <TabAtkins_> | Okay, then perhaps it should continue things. |
| 21:52 | <Hixie> | i think you're convincing me to continue rather than start afresh, yeah |
| 21:52 | <Hixie> | ok |
| 21:53 | <Hixie> | and clip |
| 21:53 | <Hixie> | the three things you can do :-) |
| 21:53 | <TabAtkins_> | Heh. |
| 21:53 | <TabAtkins_> | Okay, then perhaps it should continue things. |
| 21:53 | <Hixie> | i think you're convincing me to continue rather than start afresh, yeah |
| 21:53 | <Hixie> | ok |
| 21:53 | <TabAtkins_> | Forcing a new subpath is also trivial - just prepend an "M" with the same point that your first real command starts with. |
| 21:53 | <Hixie> | yeah |
| 21:53 | <TabAtkins_> | Forcing a new subpath is also trivial - just prepend an "M" with the same point that your first real command starts with. |
| 21:53 | <Hixie> | yeah |
| 21:53 | <TabAtkins_> | Also, you can do that *after* the conditional, which allows differing behavior from different branches. |
| 21:54 | <TabAtkins_> | Also, you can do that *after* the conditional, which allows differing behavior from different branches. |
| 21:55 | <Hixie> | um |
| 21:55 | <Hixie> | am i missing something |
| 21:55 | <Hixie> | or does SVG not say what the initial current point is |
| 21:56 | <Hixie> | um |
| 21:56 | <Hixie> | am i missing something |
| 21:56 | <Hixie> | or does SVG not say what the initial current point is |
| 21:56 | <TabAtkins_> | If you didn't start with an M, all the commands need a starting point. |
| 21:56 | <TabAtkins_> | If you didn't start with an M, all the commands need a starting point. |
| 21:56 | <Hixie> | oh i see, if you don't start with an M then the path is invalid |
| 21:56 | <Hixie> | well then |
| 21:56 | <Hixie> | that makes my earlier point a bit moot |
| 21:56 | <Hixie> | nevermind |
| 21:56 | <TabAtkins_> | Oh, indeed. Why did I remember that wrong? |
| 21:57 | <Hixie> | oh i see, if you don't start with an M then the path is invalid |
| 21:57 | <Hixie> | well then |
| 21:57 | <Hixie> | that makes my earlier point a bit moot |
| 21:57 | <Hixie> | nevermind |
| 21:57 | <TabAtkins_> | Oh, indeed. Why did I remember that wrong? |
| 21:57 | <Hixie> | dunno, i did too |
| 21:57 | <Hixie> | maybe i was confusing it with the canvas path api |
| 21:57 | <Hixie> | dunno, i did too |
| 21:57 | <Hixie> | maybe i was confusing it with the canvas path api |
| 22:02 | <TabAtkins_> | matjas: Since the CSSWG switched to the Hg repo, my service isn't necessary anymore. You can redirect your @csscommits parser to the RSS feed at |
| 22:02 | <TabAtkins_> | |
| 22:02 | <TabAtkins_> | |
| 22:02 | <TabAtkins_> | http://dvcs.w3.org/hg/csswg/rss-log |
| 22:02 | <TabAtkins_> | matjas: http://dvcs.w3.org/hg/csswg/rss-log |
| 22:03 | <TabAtkins_> | matjas: Since the CSSWG switched to the Hg repo, my service isn't necessary anymore. You can redirect your @csscommits parser to the RSS feed at |
| 22:03 | <TabAtkins_> | goddam middleclick. |
| 22:03 | <TabAtkins_> | http://dvcs.w3.org/hg/csswg/rss-log |
| 22:03 | <TabAtkins_> | matjas: http://dvcs.w3.org/hg/csswg/rss-log |
| 22:03 | <TabAtkins_> | goddam middleclick. |
| 22:04 | <heycam> | Hixie, you want the 1.1 path syntax -- 1.2T doesn't have arc commands |
| 22:04 | <heycam> | Hixie, you want the 1.1 path syntax -- 1.2T doesn't have arc commands |
| 22:15 | <Hixie> | heycam: is there anything for which i want 2.1T? |
| 22:15 | <Hixie> | heycam: is there anything for which i want 2.1T? |
| 22:15 | <heycam> | Hixie, there are a few definitions that are clearer/better, but off the top of my head I can't remember what things specifically |
| 22:16 | <heycam> | Hixie, there are a few definitions that are clearer/better, but off the top of my head I can't remember what things specifically |
| 22:16 | <heycam> | Hixie, for anything about the language or DOM itself I think you should definitely reference 1.1 |
| 22:16 | <TabAtkins_> | I was told by shepazu to reference 1.2T for language stuff. |
| 22:17 | <heycam> | Hixie, for anything about the language or DOM itself I think you should definitely reference 1.1 |
| 22:17 | <TabAtkins_> | I was told by shepazu to reference 1.2T for language stuff. |
| 22:17 | <heycam> | by language here I mean like markup, content |
| 22:17 | <TabAtkins_> | (Image Values is doing so now, for the definition of "decorated bounding box".) |
| 22:17 | <heycam> | by language here I mean like markup, content |
| 22:17 | <TabAtkins_> | (Image Values is doing so now, for the definition of "decorated bounding box".) |
| 22:17 | <heycam> | right for definitions and wordy stuff some 1.2T text is better |
| 22:17 | <TabAtkins_> | kk |
| 22:18 | <heycam> | right for definitions and wordy stuff some 1.2T text is better |
| 22:18 | <TabAtkins_> | kk |
| 22:18 | <heycam> | also shepazu wrote the improved bounding box text so of course he'd say that ;) |
| 22:18 | <TabAtkins_> | heh, kk |
| 22:18 | <heycam> | also shepazu wrote the improved bounding box text so of course he'd say that ;) |
| 22:18 | <TabAtkins_> | heh, kk |
| 22:22 | <Hixie> | heycam: k |
| 22:22 | <Hixie> | heycam: k |
| 22:22 | <Hixie> | heycam: any idea how long it'll be before there's an ED worth referencing that brings things back to reality? |
| 22:23 | <Hixie> | heycam: any idea how long it'll be before there's an ED worth referencing that brings things back to reality? |
| 22:23 | <Hixie> | or rather, that unifies svg-related stuff into one document? |
| 22:23 | <heycam> | Hixie, um, we had hoped to have something ready by next month |
| 22:24 | <heycam> | Hixie, um, we had hoped to have something ready by next month |
| 22:24 | <heycam> | Hixie, which would be at a minimum the current 1.1 spec with stub sections on features we've agreed to include in 2.0 |
| 22:24 | <heycam> | Hixie, which would be at a minimum the current 1.1 spec with stub sections on features we've agreed to include in 2.0 |
| 22:34 | <Hixie> | heycam: k |
| 22:34 | <Hixie> | heycam: btw either you are doug asked about paths and what i would need from the spec |
| 22:35 | <Hixie> | heycam: 1.1 and 1.2T are vague enough that i can just refer to them |
| 22:35 | <Hixie> | heycam: and handwave the interface between specs |
| 22:35 | <heycam> | Hixie, ok, though probably the first time I've heard you say something is vague enough ;) |
| 22:35 | <Hixie> | heycam: well i mean that it's completley underdefined and doesn't actually require that any paths draw at all in svg |
| 22:35 | <Hixie> | heycam: but that means i can just pretend that's good enough and if it's good enough to be interpreted for svg it's good enough to be interpreted for canvas :-) |
| 22:36 | <Hixie> | heycam: k |
| 22:36 | <Hixie> | heycam: btw either you are doug asked about paths and what i would need from the spec |
| 22:36 | <Hixie> | heycam: 1.1 and 1.2T are vague enough that i can just refer to them |
| 22:36 | <Hixie> | heycam: and handwave the interface between specs |
| 22:36 | <heycam> | Hixie, ok, though probably the first time I've heard you say something is vague enough ;) |
| 22:36 | <Hixie> | heycam: well i mean that it's completley underdefined and doesn't actually require that any paths draw at all in svg |
| 22:36 | <Hixie> | heycam: but that means i can just pretend that's good enough and if it's good enough to be interpreted for svg it's good enough to be interpreted for canvas :-) |
| 22:36 | <heycam> | Hixie, ok :) it should get improved as we work in SVG2 anyway, so when doing that I'll try to keep in mind how HTML is referencing it to not break things |
| 22:36 | <heycam> | s/work in/work on/ |
| 22:36 | <Hixie> | heycam: going forward though it would be nice if it was (a) actually defined in terms of testable requirements, and (b) had an interface where given a string, it would return a path (a list of subpaths each consisting of coordinates and lines between them, each subpath optionally marked as closed) |
| 22:36 | <Hixie> | heycam: k |
| 22:37 | <heycam> | Hixie, ok :) it should get improved as we work in SVG2 anyway, so when doing that I'll try to keep in mind how HTML is referencing it to not break things |
| 22:37 | <heycam> | s/work in/work on/ |
| 22:37 | <Hixie> | heycam: going forward though it would be nice if it was (a) actually defined in terms of testable requirements, and (b) had an interface where given a string, it would return a path (a list of subpaths each consisting of coordinates and lines between them, each subpath optionally marked as closed) |
| 22:37 | <Hixie> | heycam: k |
| 22:37 | <heycam> | an interface as in a spec interface definition? or an IDL interface? |
| 22:37 | <Hixie> | heycam: feel free to ask me to change things to help you out if you want me to refernece it a different way |
| 22:37 | <heycam> | an interface as in a spec interface definition? or an IDL interface? |
| 22:37 | <TabAtkins_> | heycam: Also note that CSS would like to use SVG paths *without* drawing. |
| 22:37 | <Hixie> | heycam: spec interface |
| 22:37 | <Hixie> | TabAtkins_: i use them without drawing too. so does svg actually. |
| 22:37 | <Hixie> | heycam: feel free to ask me to change things to help you out if you want me to refernece it a different way |
| 22:37 | <TabAtkins_> | heycam: Also note that CSS would like to use SVG paths *without* drawing. |
| 22:37 | <Hixie> | heycam: spec interface |
| 22:37 | <Hixie> | TabAtkins_: i use them without drawing too. so does svg actually. |
| 22:37 | <Hixie> | heycam: as in, a <dfn> of an algorithm i can just reference |
| 22:38 | <Hixie> | heycam: as in, a <dfn> of an algorithm i can just reference |
| 22:38 | <heycam> | yup ok |
| 22:38 | <heycam> | yup ok |
| 22:44 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#dom-path-addpathdata is what i have now |
| 22:45 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#dom-path-addpathdata is what i have now |
| 22:45 | <Hixie> | heycam: also, would be nice to have some way to do fragments of paths, as TabAtkins_ and i were discussing earlier |
| 22:46 | <Hixie> | heycam: also, would be nice to have some way to do fragments of paths, as TabAtkins_ and i were discussing earlier |
| 22:46 | <heycam> | Hixie, as part of the <dfn> that does path parsing? so you can parse say just "L100,100"? |
| 22:46 | <heycam> | Hixie, as part of the <dfn> that does path parsing? so you can parse say just "L100,100"? |
| 22:46 | <TabAtkins_> | heycam: Yeah, given an existing subpath as context. |
| 22:46 | <Hixie> | heycam: yeah |
| 22:46 | <heycam> | ok sure |
| 22:47 | <TabAtkins_> | heycam: Yeah, given an existing subpath as context. |
| 22:47 | <Hixie> | heycam: yeah |
| 22:47 | <heycam> | ok sure |
| 22:47 | <TabAtkins_> | (Or I suppose, without such a context, assuming an "M0 0" beforehand.) |
| 22:47 | <Hixie> | ideally given not a subpath as context, but a point |
| 22:47 | <Hixie> | and then i can just graft the first subpath i get back to the existing subpath |
| 22:47 | <Hixie> | or something |
| 22:47 | <Hixie> | i dunno |
| 22:47 | <heycam> | ok so presumably this matters just for the relative commands |
| 22:47 | <Hixie> | might not really be needed |
| 22:48 | <Hixie> | ideally given not a subpath as context, but a point |
| 22:48 | <Hixie> | and then i can just graft the first subpath i get back to the existing subpath |
| 22:48 | <Hixie> | well the idea is that you could do: |
| 22:48 | <Hixie> | or something |
| 22:48 | <Hixie> | i dunno |
| 22:48 | <heycam> | ok so presumably this matters just for the relative commands |
| 22:48 | <Hixie> | might not really be needed |
| 22:48 | <Hixie> | well the idea is that you could do: |
| 22:48 | <Hixie> | path.addPathData('M 100 100'); |
| 22:48 | <heycam> | if the output of this algorithm is a list of absolute abstract path segments |
| 22:48 | <Hixie> | if (foo) path.addPathData('L 300 100'); |
| 22:48 | <Hixie> | path.addPathData('M 100 100'); |
| 22:48 | <heycam> | if the output of this algorithm is a list of absolute abstract path segments |
| 22:48 | <Hixie> | if (foo) path.addPathData('L 300 100'); |
| 22:48 | <Hixie> | path.addPathData('v 100'); |
| 22:48 | <Hixie> | and it would either return a capital gamma or a vertical line depending on foo's value |
| 22:48 | <Hixie> | s/return/cause the path to contain/ |
| 22:49 | <Hixie> | path.addPathData('v 100'); |
| 22:49 | <Hixie> | and it would either return a capital gamma or a vertical line depending on foo's value |
| 22:49 | <Hixie> | s/return/cause the path to contain/ |
| 22:49 | <heycam> | sure, sounds reasonable |
| 22:49 | <heycam> | and a path interface that might actually be usable! |
| 22:50 | <heycam> | and a path interface that might actually be usable! |
| 22:51 | <TabAtkins_> | Yus. |
| 22:51 | <TabAtkins_> | SVG path syntax >>> canvas path API. |
| 22:51 | <TabAtkins_> | s/canvas path/current canvas path/ |
| 22:52 | <TabAtkins_> | Yus. |
| 22:52 | <TabAtkins_> | SVG path syntax >>> canvas path API. |
| 22:52 | <TabAtkins_> | s/canvas path/current canvas path/ |
| 23:35 | <Hixie> | hm |
| 23:35 | <Hixie> | dashed lines are a pain to define |
| 23:35 | <Hixie> | hm |
| 23:35 | <Hixie> | dashed lines are a pain to define |
| 23:36 | <TabAtkins_> | And SVG doesn't help you out. :/ |
| 23:37 | <TabAtkins_> | And SVG doesn't help you out. :/ |
| 23:37 | <TabAtkins_> | What's the issue you're having? |
| 23:38 | <TabAtkins_> | What's the issue you're having? |
| 23:40 | <Hixie> | TabAtkins_: so i'm defining it by saying you cut out bits of the path that aren't in the dash |
| 23:41 | <Hixie> | TabAtkins_: so i'm defining it by saying you cut out bits of the path that aren't in the dash |
| 23:41 | <Hixie> | TabAtkins_: but there's nothing to cut in the line between the last point and the first point of a closed path |
| 23:41 | <Hixie> | TabAtkins_: so i have to add it |
| 23:41 | <Hixie> | TabAtkins_: but there's nothing to cut in the line between the last point and the first point of a closed path |
| 23:41 | <Hixie> | TabAtkins_: so i have to add it |
| 23:41 | <Hixie> | TabAtkins_: but what if the whole subpath is in an "on" segment? then i don't want to add it, because i have to leave it to get the right join |
| 23:41 | <Hixie> | TabAtkins_: etc |
| 23:41 | <Hixie> | also, 0-width segments |
| 23:42 | <Hixie> | TabAtkins_: but what if the whole subpath is in an "on" segment? then i don't want to add it, because i have to leave it to get the right join |
| 23:42 | <Hixie> | TabAtkins_: etc |
| 23:42 | <Hixie> | also, 0-width segments |
| 23:42 | <TabAtkins_> | I don't understand what you mean by "nothing to cut" in closed paths. |
| 23:42 | <TabAtkins_> | I don't understand what you mean by "nothing to cut" in closed paths. |
| 23:49 | <TabAtkins_> | (Specifically, a closed path still draws dashes (and thus has stuff to cut out) on the line you mention.) |
| 23:50 | <TabAtkins_> | (Specifically, a closed path still draws dashes (and thus has stuff to cut out) on the line you mention.) |
| 23:52 | <Hixie> | i mean there's no line between the last point and the first point in the path |
| 23:52 | <Hixie> | it's implied |
| 23:52 | <Hixie> | i mean there's no line between the last point and the first point in the path |
| 23:52 | <Hixie> | so there's nothing for me to remove |
| 23:52 | <Hixie> | it's implied |
| 23:52 | <Hixie> | i actually have to _add_ the line before i can remove it |
| 23:52 | <Hixie> | so there's nothing for me to remove |
| 23:52 | <Hixie> | i actually have to _add_ the line before i can remove it |
| 23:52 | <TabAtkins_> | The .close() command doesnt' add it? |
| 23:52 | <Hixie> | it just sets a flag |
| 23:52 | <Hixie> | you can't add the line because otherwise the join is wrong |
| 23:53 | <TabAtkins_> | The .close() command doesnt' add it? |
| 23:53 | <Hixie> | it just sets a flag |
| 23:53 | <Hixie> | you can't add the line because otherwise the join is wrong |
| 23:56 | <TabAtkins_> | Oh wow, arcTo is *confusing*. |
| 23:57 | <TabAtkins_> | Oh wow, arcTo is *confusing*. |
| 23:57 | <Hixie> | that's why i added the diagrams yesterday |
| 23:57 | <Hixie> | that's why i added the diagrams yesterday |
| 23:57 | <Hixie> | with the diagrams it's not so bad |
| 23:57 | <Hixie> | (and actually is really useful for rounded corners) |
| 23:57 | <TabAtkins_> | ...would you mind if I wrote a visualizer for this that let you drag around the points/radius/etc? |
| 23:58 | <Hixie> | with the diagrams it's not so bad |
| 23:58 | <Hixie> | (and actually is really useful for rounded corners) |
| 23:58 | <TabAtkins_> | ...would you mind if I wrote a visualizer for this that let you drag around the points/radius/etc? |
| 23:58 | <Hixie> | i would love it. You'll find the code for the current diagrams in the spec in a comment, which will likely be a good starting point |
| 23:58 | <Hixie> | i would love it. You'll find the code for the current diagrams in the spec in a comment, which will likely be a good starting point |
| 23:59 | <TabAtkins_> | I guess to do a roundrect you just issue four arcTo commands in succession? |
| 23:59 | <Hixie> | (search the source for "update the label positions") |
| 23:59 | <TabAtkins_> | I guess to do a roundrect you just issue four arcTo commands in succession? |
| 23:59 | <Hixie> | you'd have some lineTos and moveTos, but yeah |
| 23:59 | <Hixie> | oh actually yeah |
| 23:59 | <Hixie> | i guess you don't even need lineTos |
| 23:59 | <TabAtkins_> | You either need to figure out where the first edge starts after the curve, or start in the middle of an edge and finish with a lineTo back to that point. |
| 23:59 | <Hixie> | (search the source for "update the label positions") |
| 23:59 | <Hixie> | you'd have some lineTos and moveTos, but yeah |
| 23:59 | <Hixie> | oh actually yeah |
| 23:59 | <Hixie> | i guess you don't even need lineTos |
| 23:59 | <TabAtkins_> | You either need to figure out where the first edge starts after the curve, or start in the middle of an edge and finish with a lineTo back to that point. |
| 23:59 | <Hixie> | yeah you start in the middle and end with a closePath |
| 23:59 | <TabAtkins_> | Yeah. |