| 00:00 | <Hixie> | yeah you start in the middle and end with a closePath |
| 00:00 | <TabAtkins_> | Yeah. |
| 00:01 | <TabAtkins_> | Ah, now I kinda understand the dash issue you're talking about. |
| 00:01 | <TabAtkins_> | Ah, now I kinda understand the dash issue you're talking about. |
| 00:03 | <Hixie> | maybe i should just handwave this rather than being overly specific about the algorithm to do this |
| 00:04 | <Hixie> | maybe i should just handwave this rather than being overly specific about the algorithm to do this |
| 00:04 | <TabAtkins_> | I suspect the problem comes from you defining the join-drawing in the wrong place. |
| 00:04 | <TabAtkins_> | I suspect the problem comes from you defining the join-drawing in the wrong place. |
| 00:04 | <TabAtkins_> | I'm trying to verify this suspicion. |
| 00:04 | <Hixie> | well, not so much the wrong place as in the wrong way |
| 00:05 | <TabAtkins_> | I'm trying to verify this suspicion. |
| 00:05 | <Hixie> | well, not so much the wrong place as in the wrong way |
| 00:05 | <Hixie> | what i should do is define something that says how you stroke a path, going from a path to another path, the latter of which, if filled, gives you what stroking the first one would give you today |
| 00:05 | <Hixie> | what i should do is define something that says how you stroke a path, going from a path to another path, the latter of which, if filled, gives you what stroking the first one would give you today |
| 00:05 | <Hixie> | then i can put all the line stuff into that algorithm |
| 00:05 | <Hixie> | instead of implying that that algorithm exists, and having multiple things in the spec imply additional steps to it |
| 00:06 | <Hixie> | then i can put all the line stuff into that algorithm |
| 00:06 | <Hixie> | instead of implying that that algorithm exists, and having multiple things in the spec imply additional steps to it |
| 00:06 | <Hixie> | but since i've no idea how to write that algorithm, i'm gonna stick to this current approach :-) |
| 00:06 | <Hixie> | but since i've no idea how to write that algorithm, i'm gonna stick to this current approach :-) |
| 00:06 | <TabAtkins_> | Oh, you mean converting 'stroke' to 'fill this path by inflating the original path somewhow'? |
| 00:06 | <TabAtkins_> | Oh, you mean converting 'stroke' to 'fill this path by inflating the original path somewhow'? |
| 00:06 | <Hixie> | yeah |
| 00:07 | <Hixie> | yeah |
| 00:07 | <Hixie> | yeah i really need to just bite the bullet and do that |
| 00:07 | <Hixie> | yeah i really need to just bite the bullet and do that |
| 00:07 | <Hixie> | this is just going to become spaghetti spec otherwise |
| 00:07 | <TabAtkins_> | SVG Vector Effects *may* have that. |
| 00:07 | <TabAtkins_> | But I'm not sure. |
| 00:07 | <TabAtkins_> | It may just handwave. |
| 00:08 | <Hixie> | this is just going to become spaghetti spec otherwise |
| 00:08 | <TabAtkins_> | (There's an effect for converting a path into the outline of stroking it.) |
| 00:08 | <TabAtkins_> | SVG Vector Effects *may* have that. |
| 00:08 | <TabAtkins_> | But I'm not sure. |
| 00:08 | <heycam> | vector effects never got to a detailed level of spec |
| 00:08 | <TabAtkins_> | It may just handwave. |
| 00:08 | <TabAtkins_> | (There's an effect for converting a path into the outline of stroking it.) |
| 00:08 | <heycam> | vector effects never got to a detailed level of spec |
| 00:08 | <TabAtkins_> | That's what I feared. |
| 00:08 | <heycam> | stroking/outsetting/whatever a path is quite complicated |
| 00:08 | <TabAtkins_> | That's what I feared. |
| 00:08 | <heycam> | stroking/outsetting/whatever a path is quite complicated |
| 00:08 | <TabAtkins_> | Yup. |
| 00:08 | <Hixie> | canvas already has a method that takes a path and strokes it and gives you back another path representing the stroke |
| 00:08 | <Hixie> | (as of, like, 24 hours ago) |
| 00:08 | <heycam> | how do you define it? :) |
| 00:09 | <TabAtkins_> | Yup. |
| 00:09 | <Hixie> | canvas already has a method that takes a path and strokes it and gives you back another path representing the stroke |
| 00:09 | <Hixie> | (as of, like, 24 hours ago) |
| 00:09 | <heycam> | how do you define it? :) |
| 00:09 | <Hixie> | "Create a new list of subpaths d, consisting of the subpaths necessary to describe the result of tracing the subpaths in c, in the same order, while applying the line styles of a (the lineWidth, lineCap, lineJoin, and (if appropriate) miterLimit attributes). Subpaths in d must wind clockwise, regardless of the direction of paths in c." |
| 00:09 | Hixie | waves his hand meaningfully |
| 00:09 | <Hixie> | "Create a new list of subpaths d, consisting of the subpaths necessary to describe the result of tracing the subpaths in c, in the same order, while applying the line styles of a (the lineWidth, lineCap, lineJoin, and (if appropriate) miterLimit attributes). Subpaths in d must wind clockwise, regardless of the direction of paths in c." |
| 00:09 | Hixie | waves his hand meaningfully |
| 00:09 | <heycam> | i mean i think it's fine to handwave the actual stroking part |
| 00:09 | <heycam> | since it's a well understood graphical primitive |
| 00:10 | <heycam> | i mean i think it's fine to handwave the actual stroking part |
| 00:10 | <heycam> | since it's a well understood graphical primitive |
| 00:10 | <Hixie> | yeah well it is until you end up having to define how line joins, line caps, and dashing all interact |
| 00:10 | <Hixie> | yeah well it is until you end up having to define how line joins, line caps, and dashing all interact |
| 00:10 | TabAtkins_ | needs to file some spec bugs on SVG2... |
| 00:10 | <heycam> | mind you, while all 2d graphics libraries will be able to immediately paint a stroked path, not all can return you a path that presents that stroke shape |
| 00:10 | TabAtkins_ | needs to file some spec bugs on SVG2... |
| 00:10 | <heycam> | mind you, while all 2d graphics libraries will be able to immediately paint a stroked path, not all can return you a path that presents that stroke shape |
| 00:10 | <Hixie> | then it starts getting less and less like handwaving and more and more like trying to pin a tail on a donkey without ever drawing the donkey |
| 00:10 | <heycam> | *represents |
| 00:10 | <heycam> | stroke the tail on the donkey :) |
| 00:11 | <Hixie> | then it starts getting less and less like handwaving and more and more like trying to pin a tail on a donkey without ever drawing the donkey |
| 00:11 | <heycam> | *represents |
| 00:11 | <heycam> | stroke the tail on the donkey :) |
| 00:11 | <Hixie> | heycam: i expect a lot of these graphical libraries are suddenly gonna find a bunch of patches going their way to implement a series of new features... |
| 00:11 | <heycam> | yeah |
| 00:11 | <Hixie> | heycam: i expect a lot of these graphical libraries are suddenly gonna find a bunch of patches going their way to implement a series of new features... |
| 00:11 | <heycam> | yeah |
| 00:11 | <Hixie> | either that or i'll be removing some of these new canvas features soon when implementors' eyes bug out :-) |
| 00:12 | <Hixie> | either that or i'll be removing some of these new canvas features soon when implementors' eyes bug out :-) |
| 00:14 | <Hixie> | bbl |
| 00:14 | <Hixie> | bbl |
| 00:24 | <TabAtkins_> | Hixie: Dirk Schulze points out that SVG's path parser won't ever throw errors; each individual construction greedily consumes as much as possible, and if there is any left over when the root construction can no longer consume anything while staying valid, it's thrown away. |
| 00:24 | <TabAtkins_> | Hixie: Dirk Schulze points out that SVG's path parser won't ever throw errors; each individual construction greedily consumes as much as possible, and if there is any left over when the root construction can no longer consume anything while staying valid, it's thrown away. |
| 00:25 | <TabAtkins_> | And so, step 2 of the list introduced with "The addPathData(d) method..." is unnecessary, as no errors can ever be thrown. |
| 00:25 | <TabAtkins_> | Or rather, as step 1 can never fail. |
| 00:26 | <TabAtkins_> | And so, step 2 of the list introduced with "The addPathData(d) method..." is unnecessary, as no errors can ever be thrown. |
| 00:26 | <TabAtkins_> | Or rather, as step 1 can never fail. |
| 00:26 | <TabAtkins_> | (Outside of the standard hardware-limitations clause.) |
| 00:26 | <TabAtkins_> | (Outside of the standard hardware-limitations clause.) |
| 01:01 | <Hixie> | TabAtkins_: where does it say that? |
| 01:01 | <Hixie> | TabAtkins_: where does it say that? |
| 01:02 | <TabAtkins_> | Just below the BNF grammar. |
| 01:03 | <TabAtkins_> | Just below the BNF grammar. |
| 02:21 | <llrcombs> | would it be a reasonable request to allow messages between Web Workers to include typed arrays? |
| 02:22 | <llrcombs> | would it be a reasonable request to allow messages between Web Workers to include typed arrays? |
| 02:22 | <llrcombs> | I'd like to have one worker manage several worker threads, sending Int8Arrays and similar between them, to calculate pruning tables more quickly than with just one worker |
| 02:22 | <llrcombs> | I'd like to have one worker manage several worker threads, sending Int8Arrays and similar between them, to calculate pruning tables more quickly than with just one worker |
| 02:24 | <llrcombs> | oh, it looks like transferable objects do that |
| 02:24 | <llrcombs> | is that in spec, or just a WebKit extension? |
| 02:24 | <MikeSmith> | llrcombs: in the spec |
| 02:25 | <llrcombs> | oh, it looks like transferable objects do that |
| 02:25 | <llrcombs> | is that in spec, or just a WebKit extension? |
| 02:25 | <MikeSmith> | llrcombs: in the spec |
| 02:25 | <llrcombs> | cool! |
| 02:25 | <llrcombs> | cool! |
| 02:28 | <MikeSmith> | video peoples, how does seeking and adjustment of playback rate work with encrypted video? |
| 02:28 | <MikeSmith> | video peoples, how does seeking and adjustment of playback rate work with encrypted video? |
| 02:28 | <MikeSmith> | would it just work the same? |
| 02:29 | <MikeSmith> | would it just work the same? |
| 02:29 | <MikeSmith> | it seems like the encryption could muff with the ability to do those operations from JS |
| 02:29 | <MikeSmith> | it seems like the encryption could muff with the ability to do those operations from JS |
| 02:30 | <MikeSmith> | Hixie: thanks for pushing to the W3C versions |
| 02:30 | <Hixie> | np |
| 02:30 | <Hixie> | TabAtkins_: ah, will look |
| 02:31 | <MikeSmith> | Hixie: thanks for pushing to the W3C versions |
| 02:31 | <Hixie> | np |
| 02:31 | <Hixie> | TabAtkins_: ah, will look |
| 02:32 | <MikeSmith> | Hixie: ah this doesn't include the replacement of the code-point names? |
| 02:33 | <MikeSmith> | Hixie: ah this doesn't include the replacement of the code-point names? |
| 02:33 | <MikeSmith> | not yet integrated that script? |
| 02:34 | <MikeSmith> | not yet integrated that script? |
| 02:40 | <MikeSmith> | hsivonen: I know you are not around right now but as far as what I was talking about earlier, regarding how to make the local validator build and install easier for end users, I wonder if it would help to have the build emit a message saying, "If you have problem with building or installing the validator and need help in real time, you can join the #whatwg channel on irc.freenode.net and ask there." |
| 02:41 | <MikeSmith> | hsivonen: I know you are not around right now but as far as what I was talking about earlier, regarding how to make the local validator build and install easier for end users, I wonder if it would help to have the build emit a message saying, "If you have problem with building or installing the validator and need help in real time, you can join the #whatwg channel on irc.freenode.net and ask there." |
| 02:41 | <MikeSmith> | scott_gonzalez: fwiw, I pushed a change to the validator sources a few hours ago that streamlines the initial install |
| 02:42 | <MikeSmith> | scott_gonzalez: fwiw, I pushed a change to the validator sources a few hours ago that streamlines the initial install |
| 02:42 | <MikeSmith> | it should cut down the install time considerably |
| 02:42 | <MikeSmith> | it should cut down the install time considerably |
| 02:43 | <MikeSmith> | scott_gonzalez: I hope ultimately you guys could switch to using a local instance of the validator to run your validation tests |
| 02:43 | <MikeSmith> | it's just way better in many ways |
| 02:44 | <MikeSmith> | scott_gonzalez: I hope ultimately you guys could switch to using a local instance of the validator to run your validation tests |
| 02:44 | <MikeSmith> | it's just way better in many ways |
| 02:44 | <MikeSmith> | e.g., it handles data-* attributes just fine without you needing to filter out the errors |
| 02:44 | <MikeSmith> | e.g., it handles data-* attributes just fine without you needing to filter out the errors |
| 02:45 | <MikeSmith> | and it is at least an order of magnitude faster than any doing it with the jing-html thing I pointed you to |
| 02:46 | <MikeSmith> | and it is at least an order of magnitude faster than any doing it with the jing-html thing I pointed you to |
| 02:46 | <MikeSmith> | for a normal file it takes like 100ms or 200ms to validate |
| 02:47 | <MikeSmith> | for a normal file it takes like 100ms or 200ms to validate |
| 02:47 | <MikeSmith> | for really small files it takes only 50ms |
| 02:47 | <MikeSmith> | or less |
| 02:47 | <MikeSmith> | for really small files it takes only 50ms |
| 02:47 | <MikeSmith> | or less |
| 02:50 | <MikeSmith> | Hixie: sorry man, I see that you actually did apply it |
| 02:50 | <MikeSmith> | Hixie: sorry man, I see that you actually did apply it |
| 02:50 | MikeSmith | kicks his browser cache in the teeth |
| 02:50 | MikeSmith | kicks his browser cache in the teeth |
| 02:52 | <MikeSmith> | matjas: about "criteria that cannot be expressed by a DTD, but can still be checked by a machine”, there are many |
| 02:52 | <MikeSmith> | so please (re)ping me about that when you are back |
| 02:53 | <MikeSmith> | matjas: about "criteria that cannot be expressed by a DTD, but can still be checked by a machine”, there are many |
| 02:53 | <MikeSmith> | so please (re)ping me about that when you are back |
| 02:54 | <MikeSmith> | one example is that schema languages can't check the text content of elements |
| 02:54 | <MikeSmith> | one example is that schema languages can't check the text content of elements |
| 02:54 | <MikeSmith> | like for <time> and <script> and <style> the spec has some specific document-conformance requirements for their text content |
| 02:55 | <MikeSmith> | like for <time> and <script> and <style> the spec has some specific document-conformance requirements for their text content |
| 02:55 | <MikeSmith> | theoretically that could be checked using a regexp |
| 02:56 | <MikeSmith> | theoretically that could be checked using a regexp |
| 02:56 | <MikeSmith> | but it's not practical and it's also the suckiest possible way to do it from a user-experience POV |
| 02:56 | <MikeSmith> | but it's not practical and it's also the suckiest possible way to do it from a user-experience POV |
| 02:56 | <MikeSmith> | because the only possible error you get back is "fail" |
| 02:56 | <MikeSmith> | with no details about why it's failed |
| 02:56 | <MikeSmith> | that is, which part is invalid |
| 02:57 | <MikeSmith> | because the only possible error you get back is "fail" |
| 02:57 | <MikeSmith> | with no details about why it's failed |
| 02:57 | <MikeSmith> | that is, which part is invalid |
| 02:57 | <MikeSmith> | in contrast the way those text-content checks are implemented in validator.nu, it attempts to actually report the actual specific error |
| 02:58 | <MikeSmith> | in contrast the way those text-content checks are implemented in validator.nu, it attempts to actually report the actual specific error |
| 02:58 | <MikeSmith> | but the location |
| 02:58 | <MikeSmith> | *both the location |
| 02:58 | <MikeSmith> | line number and column number |
| 02:58 | <MikeSmith> | *both the location |
| 02:58 | <MikeSmith> | line number and column number |
| 02:58 | <MikeSmith> | and also what part of the string is wrong |
| 02:59 | <MikeSmith> | and also what part of the string is wrong |
| 02:59 | <MikeSmith> | e.g., it says "Expected a foo character here but found bar" |
| 03:02 | <MikeSmith> | https://bitbucket.org/validator/syntax/src/tip/relaxng/datatype/java/src/org/whattf/datatype/ScriptDocumentation.java |
| 03:03 | <MikeSmith> | https://bitbucket.org/validator/syntax/src/tip/relaxng/datatype/java/src/org/whattf/datatype/ScriptDocumentation.java |
| 03:04 | <MikeSmith> | and https://bitbucket.org/validator/syntax/src/tip/relaxng/datatype/java/src/org/whattf/datatype/FunctionBody.java |
| 03:04 | <MikeSmith> | and https://bitbucket.org/validator/syntax/src/tip/relaxng/datatype/java/src/org/whattf/datatype/FunctionBody.java |
| 03:04 | <MikeSmith> | which validates JS by passing it off to Rhino to check |
| 03:05 | <MikeSmith> | which validates JS by passing it off to Rhino to check |
| 03:10 | <Hixie> | MikeSmith: yeah, script is in |
| 03:10 | <Hixie> | MikeSmith: yeah, script is in |
| 03:10 | <MikeSmith> | yep I see now |
| 03:10 | <MikeSmith> | thanks man |
| 03:11 | <MikeSmith> | yep I see now |
| 03:11 | <MikeSmith> | thanks man |
| 03:12 | <Hixie> | MikeSmith: i no longer make any promises that the w3c spec says what it should |
| 03:12 | <Hixie> | MikeSmith: i no longer make any promises that the w3c spec says what it should |
| 03:12 | <MikeSmith> | yeah I know |
| 03:12 | <MikeSmith> | I am hoping we can reverse that change actually |
| 03:12 | <MikeSmith> | it was misguided from the get-go |
| 03:13 | <MikeSmith> | yeah I know |
| 03:13 | <Hixie> | no kidding |
| 03:13 | <MikeSmith> | I am hoping we can reverse that change actually |
| 03:13 | <MikeSmith> | it was misguided from the get-go |
| 03:13 | <Hixie> | no kidding |
| 03:13 | <MikeSmith> | need to put the brakes on this stuff |
| 03:14 | <MikeSmith> | need to put the brakes on this stuff |
| 03:14 | <MikeSmith> | draw the line between plain nuisances and at-least-marginally-substantial |
| 03:15 | <MikeSmith> | draw the line between plain nuisances and at-least-marginally-substantial |
| 03:15 | <MikeSmith> | that "issue" comes nowhere near the normal "I can live with it" criteria |
| 03:15 | <MikeSmith> | that "issue" comes nowhere near the normal "I can live with it" criteria |
| 03:16 | <MikeSmith> | I wish the issue proliferators would exercise better judgment |
| 03:16 | <MikeSmith> | I wish the issue proliferators would exercise better judgment |
| 03:18 | <Hixie> | the system is explictly designed to enable them to raise issues and waste a lot of time |
| 03:18 | <Hixie> | that's literally the entire purpose of the system |
| 03:19 | <Hixie> | the system is explictly designed to enable them to raise issues and waste a lot of time |
| 03:19 | <Hixie> | that's literally the entire purpose of the system |
| 03:19 | <Hixie> | (though by its designers it is phrased as "discourage people by making such issues take a lot of time") |
| 03:19 | <Hixie> | (but that clearly shows a lack of understanding of the social dynamics) |
| 03:19 | <Hixie> | (though by its designers it is phrased as "discourage people by making such issues take a lot of time") |
| 03:19 | <Hixie> | (but that clearly shows a lack of understanding of the social dynamics) |
| 03:24 | <MikeSmith> | Hixie: that was not the purpose the designer of the system intended |
| 03:24 | <Hixie> | what was the purpose? |
| 03:24 | <MikeSmith> | Hixie: that was not the purpose the designer of the system intended |
| 03:24 | <Hixie> | what was the purpose? |
| 03:24 | <Hixie> | i've heard chairs explicitly tell me that was the goal -- to make raising issues time consuming so that only important issues would get raised |
| 03:25 | <Hixie> | i've heard chairs explicitly tell me that was the goal -- to make raising issues time consuming so that only important issues would get raised |
| 03:25 | <MikeSmith> | I don't know which chairs said that but I would imagine othermaciej doesn't see that as a goal |
| 03:25 | <MikeSmith> | I don't know which chairs said that but I would imagine othermaciej doesn't see that as a goal |
| 03:25 | <MikeSmith> | anyway I don't want to speak for him |
| 03:26 | <MikeSmith> | anyway I don't want to speak for him |
| 03:26 | <MikeSmith> | I think the decision policy was designed in good faith to enable resolution on bugs where we otherwise couldn't get agreement |
| 03:26 | <MikeSmith> | I think the decision policy was designed in good faith to enable resolution on bugs where we otherwise couldn't get agreement |
| 03:26 | <Hixie> | if that was the goal, then it's way overengineered, and doesn't work. |
| 03:27 | <Hixie> | if that was the goal, then it's way overengineered, and doesn't work. |
| 03:27 | <MikeSmith> | it's just the way it's been applied, it's ended up being used as a blunt instrument |
| 03:27 | <MikeSmith> | it's just the way it's been applied, it's ended up being used as a blunt instrument |
| 03:27 | <MikeSmith> | and massively abused by a very small number of WG participants |
| 03:28 | <MikeSmith> | and massively abused by a very small number of WG participants |
| 03:28 | <MikeSmith> | Hixie: yeah I think it's worth looking at re-engineering it |
| 03:29 | <MikeSmith> | Hixie: yeah I think it's worth looking at re-engineering it |
| 03:29 | <MikeSmith> | but pausing to do that at this point seems like something that's unlikely to happen |
| 03:29 | <MikeSmith> | but pausing to do that at this point seems like something that's unlikely to happen |
| 03:29 | <Hixie> | i think the best part of the process right now is the way that it only kicks in if the editor disagrees with someone, but when that someone proposes an alternative, the editor has to do extra work to repeat the objection for it to be considered |
| 03:29 | <MikeSmith> | and filing bugs piecemeal against the decision policy is not really workable either |
| 03:30 | <Hixie> | i think the best part of the process right now is the way that it only kicks in if the editor disagrees with someone, but when that someone proposes an alternative, the editor has to do extra work to repeat the objection for it to be considered |
| 03:30 | <MikeSmith> | and filing bugs piecemeal against the decision policy is not really workable either |
| 03:30 | <Hixie> | and has to do so for _every single issue_ raised, since for few issues do people actually care enough even if they agree with the editor |
| 03:30 | <MikeSmith> | I hear you |
| 03:30 | <Hixie> | and has to do so for _every single issue_ raised, since for few issues do people actually care enough even if they agree with the editor |
| 03:30 | <MikeSmith> | I hear you |
| 03:30 | <othermaciej_> | Hixie: Path having a CTM is weird |
| 03:30 | <Hixie> | (the net result being i don't bother anymore and the w3c copy of the spec is getting more and more crazy) |
| 03:31 | <othermaciej_> | Hixie: Path having a CTM is weird |
| 03:31 | <Hixie> | (the net result being i don't bother anymore and the w3c copy of the spec is getting more and more crazy) |
| 03:31 | <Hixie> | othermaciej_: agreed. not sure how else to make it possible to do things like have another path stamped onto a path in four different positions, rotations, and skews. |
| 03:31 | <Hixie> | othermaciej_: agreed. not sure how else to make it possible to do things like have another path stamped onto a path in four different positions, rotations, and skews. |
| 03:31 | <MikeSmith> | Hixie: yeah I realize that too and maybe that is an inevitable consequence of this arrangement and maybe that's where we would have ended up regardless of the particulars of the decision polity |
| 03:32 | <MikeSmith> | Hixie: yeah I realize that too and maybe that is an inevitable consequence of this arrangement and maybe that's where we would have ended up regardless of the particulars of the decision polity |
| 03:32 | <othermaciej_> | Hixie: CGPath supports transforming a (whole) path and concatenating paths |
| 03:32 | <othermaciej_> | Hixie: CGPath supports transforming a (whole) path and concatenating paths |
| 03:32 | <othermaciej_> | Hixie: that is much more logical from my POV |
| 03:33 | <othermaciej_> | Hixie: that is much more logical from my POV |
| 03:33 | <othermaciej_> | CG also has a Transform object, which makes that approach more convenient; but plausibly one could use SVGMatrix to represent an affine transform |
| 03:33 | <othermaciej_> | CG also has a Transform object, which makes that approach more convenient; but plausibly one could use SVGMatrix to represent an affine transform |
| 03:33 | <Hixie> | othermaciej_: yeah, one of the changes i'm doing soon is adding a transform object to the three objects that have a transformation matrix |
| 03:34 | <Hixie> | othermaciej_: yeah, one of the changes i'm doing soon is adding a transform object to the three objects that have a transformation matrix |
| 03:34 | <othermaciej_> | I guess you already have a way to concatenate paths, so a way to one-shot transform a path could replace the weird concept of path having a CTM and being able to invoke transform operators on it |
| 03:35 | <othermaciej_> | I guess you already have a way to concatenate paths, so a way to one-shot transform a path could replace the weird concept of path having a CTM and being able to invoke transform operators on it |
| 03:35 | <jacobolus> | paul_irish: okay, it went through a few edits, but I have a suggestion on your requestAnimationFrame polyfill gist: https://gist.github.com/1579671#comments |
| 03:35 | <jacobolus> | paul_irish: okay, it went through a few edits, but I have a suggestion on your requestAnimationFrame polyfill gist: https://gist.github.com/1579671#comments |
| 03:35 | <othermaciej_> | also addFill vs. addStroke is weird |
| 03:36 | <Hixie> | othermaciej_: that would make it a two-step process to add text to a path in a transformed manner (first add text to another path, then transform that path, then add that path to the one you want the text on) |
| 03:36 | <Hixie> | othermaciej_: that would make it a two-step process to add text to a path in a transformed manner (first add text to another path, then transform that path, then add that path to the one you want the text on) |
| 03:36 | <othermaciej_> | I see what you are getting at, but it is a confusing API, because (if I understand correctly), if you addFill a path to another path, then stroke the resulting path object to a canvas, you get all stroke and no fill |
| 03:36 | <jacobolus> | bb10 |
| 03:37 | <othermaciej_> | I see what you are getting at, but it is a confusing API, because (if I understand correctly), if you addFill a path to another path, then stroke the resulting path object to a canvas, you get all stroke and no fill |
| 03:37 | <jacobolus> | bb10 |
| 03:37 | <Hixie> | yeah i wanted to call "addFill" something like just "addPath" but it seemed better to keep the consistency with the rest of the API, which always has pairs of fill/stroke methods |
| 03:37 | <Hixie> | yeah i wanted to call "addFill" something like just "addPath" but it seemed better to keep the consistency with the rest of the API, which always has pairs of fill/stroke methods |
| 03:37 | <Hixie> | since i knew we'd also have addStroke |
| 03:38 | <Hixie> | since i knew we'd also have addStroke |
| 03:38 | <othermaciej_> | the way CG does this is with CGPathAddPath and CGPathCreateCopyByStrokingPath |
| 03:38 | <Hixie> | CG's approach seems to involve a lot more temporaries |
| 03:38 | <othermaciej_> | what you call addFill to me makes more sense as addPath and is the common case |
| 03:38 | <othermaciej_> | the way CG does this is with CGPathAddPath and CGPathCreateCopyByStrokingPath |
| 03:38 | <Hixie> | CG's approach seems to involve a lot more temporaries |
| 03:38 | <othermaciej_> | what you call addFill to me makes more sense as addPath and is the common case |
| 03:38 | <othermaciej_> | whereas your naming would lead authors to believe that addStroke does the normal thing, when what it does is weird and not usually needed |
| 03:39 | <othermaciej_> | whereas your naming would lead authors to believe that addStroke does the normal thing, when what it does is weird and not usually needed |
| 03:39 | <othermaciej_> | your approach requires a temporary to create a path outlining the strokes of a path in any case |
| 03:40 | <othermaciej_> | your approach requires a temporary to create a path outlining the strokes of a path in any case |
| 03:40 | <othermaciej_> | it just lets you save a temporary in the (unusual) case that you want to add that to another path |
| 03:40 | <othermaciej_> | it just lets you save a temporary in the (unusual) case that you want to add that to another path |
| 03:41 | <Hixie> | and when you add text, and a whole bunch of other cases |
| 03:42 | <Hixie> | and when you add text, and a whole bunch of other cases |
| 03:43 | <othermaciej_> | yeah, I think the result of that saving of temporaries in what are relatively rare use cases makes the API as a whole needlessly confusing |
| 03:44 | <othermaciej_> | yeah, I think the result of that saving of temporaries in what are relatively rare use cases makes the API as a whole needlessly confusing |
| 03:44 | <othermaciej_> | it would also make creating a simple Path more expensive to some extent, since it would have to contain more than just a single platform-native path object for most graphics APIs of interest |
| 03:45 | <othermaciej_> | it would also make creating a simple Path more expensive to some extent, since it would have to contain more than just a single platform-native path object for most graphics APIs of interest |
| 03:45 | <Hixie> | i don't really see what's confusing |
| 03:45 | <Hixie> | i don't really see what's confusing |
| 03:45 | <Hixie> | it's exactly like using the canvas api today |
| 03:45 | <Hixie> | just one step removed |
| 03:45 | <Hixie> | it's exactly like using the canvas api today |
| 03:45 | <Hixie> | just one step removed |
| 03:46 | <othermaciej_> | I doubt most people would understand what Path.addFill() does just by analogy to Canvas.fill() |
| 03:46 | <othermaciej_> | I doubt most people would understand what Path.addFill() does just by analogy to Canvas.fill() |
| 03:46 | <othermaciej_> | and like I said, I think you optimized for performance of the rare case at expense of the common case |
| 03:46 | <othermaciej_> | it's also non-obvious that Path.rotate() would not in fact rotate the path |
| 03:47 | <othermaciej_> | and like I said, I think you optimized for performance of the rare case at expense of the common case |
| 03:47 | <othermaciej_> | it's also non-obvious that Path.rotate() would not in fact rotate the path |
| 03:47 | <othermaciej_> | where it might be less surprising in the canvas case that it won't rotate what has already been drawn |
| 03:47 | <othermaciej_> | where it might be less surprising in the canvas case that it won't rotate what has already been drawn |
| 03:47 | <othermaciej_> | anyway I'll think about it more, check with our graphics-y folks, and provide feedback |
| 03:48 | <othermaciej_> | anyway I'll think about it more, check with our graphics-y folks, and provide feedback |
| 03:48 | <Hixie> | k |
| 03:48 | <Hixie> | please do also see the canvas wiki page |
| 03:48 | <Hixie> | k |
| 03:48 | <Hixie> | please do also see the canvas wiki page |
| 03:48 | <Hixie> | as the general pattern of support transforms is used for transforming patterns too |
| 03:48 | <Hixie> | supporting |
| 03:49 | <Hixie> | as the general pattern of support transforms is used for transforming patterns too |
| 03:49 | <Hixie> | supporting |
| 03:52 | <othermaciej_> | (I'm not sure how practical it is to implement adding glyph shapes for text to a path but it's certainly a neat feature) |
| 03:52 | <othermaciej_> | (I'm not sure how practical it is to implement adding glyph shapes for text to a path but it's certainly a neat feature) |
| 03:57 | <jacobolus> | TabAtkins_, Hixie: while you’re talking about stroking paths, &c., is there anything specific you’re looking for feedback about? |
| 03:58 | <jacobolus> | TabAtkins_, Hixie: while you’re talking about stroking paths, &c., is there anything specific you’re looking for feedback about? |
| 04:00 | <Hixie> | jacobolus: http://wiki.whatwg.org/wiki/Canvas#Proposals and the corresponding new stuff in http://www.whatwg.org/specs/web-apps/current-work/#2dcontext |
| 04:01 | <Hixie> | jacobolus: http://wiki.whatwg.org/wiki/Canvas#Proposals and the corresponding new stuff in http://www.whatwg.org/specs/web-apps/current-work/#2dcontext |
| 04:02 | <othermaciej_> | adding text to a path does seem plausibly implementable at least on mac (though non-trivial) |
| 04:02 | <othermaciej_> | adding text to a path does seem plausibly implementable at least on mac (though non-trivial) |
| 04:08 | <jacobolus> | Hixie: I gotta say, having browsers just optimize & fix the bugs in their SVG implementations would handle a lot of this :) |
| 04:09 | <jacobolus> | Hixie: I gotta say, having browsers just optimize & fix the bugs in their SVG implementations would handle a lot of this :) |
| 04:10 | <jacobolus> | but improving canvas is nice too |
| 04:10 | <jacobolus> | but improving canvas is nice too |
| 04:12 | <jacobolus> | In particular, use cases where UI elements are being drawn using canvas, and developers want to have user selection/manipulation w/ keyboard navigation, focus rings, etc. doesn’t seem like the right use for canvas vs. some actual vector/object based API |
| 04:12 | <jacobolus> | In particular, use cases where UI elements are being drawn using canvas, and developers want to have user selection/manipulation w/ keyboard navigation, focus rings, etc. doesn’t seem like the right use for canvas vs. some actual vector/object based API |
| 04:15 | <Hixie> | jacobolus: ain't much you can do to svg to address the use case of "immediate mode graphics", it's a retained-mode api :-) |
| 04:15 | <Hixie> | jacobolus: ain't much you can do to svg to address the use case of "immediate mode graphics", it's a retained-mode api :-) |
| 04:15 | <jacobolus> | what's immediate-mode gfx? |
| 04:15 | <Hixie> | the opposite of retained-mode |
| 04:16 | <jacobolus> | what's immediate-mode gfx? |
| 04:16 | <Hixie> | the opposite of retained-mode |
| 04:16 | <jacobolus> | as in, you make them and only the result stays around but not the process? |
| 04:16 | <jacobolus> | as in, you make them and only the result stays around but not the process? |
| 04:17 | <jacobolus> | but the use cases being asked for are ones where you care about accessing the objects/shapes well after they are initially drawn. If that’s what you want, it seems like a bad time to use an "immediate mode graphics" API in general |
| 04:18 | <jacobolus> | but the use cases being asked for are ones where you care about accessing the objects/shapes well after they are initially drawn. If that’s what you want, it seems like a bad time to use an "immediate mode graphics" API in general |
| 04:18 | <jacobolus> | I think part of the problem may be that 99% of people using the canvas API aren’t actually playing to the strengths of the API, and are ignoring transformations and the context stack |
| 04:19 | <jacobolus> | I think part of the problem may be that 99% of people using the canvas API aren’t actually playing to the strengths of the API, and are ignoring transformations and the context stack |
| 04:19 | <jacobolus> | which are very powerful tools for building up your own abstractions, especially when using functional or concatenative programming style |
| 04:19 | <jacobolus> | which are very powerful tools for building up your own abstractions, especially when using functional or concatenative programming style |
| 04:19 | <jacobolus> | for example, it's completely trivial to define a function which draws an ellipse |
| 04:19 | <Hixie> | jacobolus: as in, no DOM |
| 04:20 | <jacobolus> | for example, it's completely trivial to define a function which draws an ellipse |
| 04:20 | <Hixie> | jacobolus: as in, no DOM |
| 04:20 | <jacobolus> | right. but many of the suggested use cases are ones where people are basically asking for DOM-like features |
| 04:20 | <jacobolus> | right. but many of the suggested use cases are ones where people are basically asking for DOM-like features |
| 04:20 | <Hixie> | given the number of requests we've had for ellipses, i don't know that i'd use the word "trivial" |
| 04:20 | <Hixie> | they're asking for DOM-like features but don't want to have a scene graph |
| 04:20 | <jacobolus> | to draw an ellipse, just save the context, do a transformation, draw a circle, and restore the context |
| 04:20 | <Hixie> | that skews the stroke |
| 04:21 | <Hixie> | given the number of requests we've had for ellipses, i don't know that i'd use the word "trivial" |
| 04:21 | <Hixie> | they're asking for DOM-like features but don't want to have a scene graph |
| 04:21 | <jacobolus> | to draw an ellipse, just save the context, do a transformation, draw a circle, and restore the context |
| 04:21 | <Hixie> | that skews the stroke |
| 04:21 | <jacobolus> | not if you restore the context before stroking |
| 04:21 | <jacobolus> | not if you restore the context before stroking |
| 04:21 | <jamesr> | how do you get the stroke to be an ellipse then? |
| 04:21 | <jacobolus> | the stroke shape is based on the current transformation, not the transformation when part of the path was created |
| 04:22 | <jamesr> | how do you get the stroke to be an ellipse then? |
| 04:22 | <jacobolus> | the stroke shape is based on the current transformation, not the transformation when part of the path was created |
| 04:22 | <Hixie> | i don't see how that gives you ellipsoid rounded corners without some complicated maths |
| 04:22 | <Hixie> | anyway, supporting ellipses is easy, so why not do it since people want it |
| 04:22 | <Hixie> | i don't see how that gives you ellipsoid rounded corners without some complicated maths |
| 04:22 | <Hixie> | anyway, supporting ellipses is easy, so why not do it since people want it |
| 04:22 | <jacobolus> | Hixie: try it! |
| 04:23 | <jacobolus> | Hixie: try it! |
| 04:25 | <jacobolus> | drawEllipse = function (ctx, a, b) { ctx.save(); ctx.scale(a, b); ctx.arc(0, 0, 1, 0, 2*Math.PI); ctx.restore(); } |
| 04:25 | <jacobolus> | drawEllipse = function (ctx, a, b) { ctx.save(); ctx.scale(a, b); ctx.arc(0, 0, 1, 0, 2*Math.PI); ctx.restore(); } |
| 04:25 | <Hixie> | that's not an ellipsoid rounded corner |
| 04:26 | <Hixie> | that's not an ellipsoid rounded corner |
| 04:26 | <jacobolus> | what do you mean? |
| 04:26 | <jacobolus> | oh |
| 04:26 | <jacobolus> | what do you mean? |
| 04:26 | <jacobolus> | oh |
| 04:26 | <jacobolus> | okay, that one takes 3 more lines of code |
| 04:26 | <jacobolus> | but is really not a "basic" shape |
| 04:26 | <Hixie> | say i want a rectangle from 0,0 to 100,100 and each corner is to have a twice-as-wide-as-high ellipsoid corner |
| 04:26 | <jacobolus> | the reason not to add every shape anyone has ever heard of is that bloating APIs is really annoying |
| 04:26 | <Hixie> | with the proposal in the spec, that's like four lines of code |
| 04:27 | <jacobolus> | okay, that one takes 3 more lines of code |
| 04:27 | <jacobolus> | but is really not a "basic" shape |
| 04:27 | <Hixie> | say i want a rectangle from 0,0 to 100,100 and each corner is to have a twice-as-wide-as-high ellipsoid corner |
| 04:27 | <Hixie> | adding one method for ellipses is hardly "bloat" |
| 04:27 | <jacobolus> | the reason not to add every shape anyone has ever heard of is that bloating APIs is really annoying |
| 04:27 | <Hixie> | with the proposal in the spec, that's like four lines of code |
| 04:27 | <Hixie> | adding one method for ellipses is hardly "bloat" |
| 04:27 | <jacobolus> | Hixie: how often in practice have you wanted such a shape? |
| 04:27 | <jacobolus> | Hixie: how often in practice have you wanted such a shape? |
| 04:27 | <jacobolus> | this ellipsoid chorner shape |
| 04:27 | <jacobolus> | *corner |
| 04:27 | <Hixie> | me, never. but then i've hardly ever needed the path stuff at all. in practice we've received multiple requests for ellipses over the last year or so |
| 04:27 | <Hixie> | it's one of the most-requested features. |
| 04:28 | <jacobolus> | this ellipsoid chorner shape |
| 04:28 | <jacobolus> | *corner |
| 04:28 | <Hixie> | me, never. but then i've hardly ever needed the path stuff at all. in practice we've received multiple requests for ellipses over the last year or so |
| 04:28 | <jacobolus> | yes, but I would suggest these are from people who don't know how to draw an ellipse using the existing API |
| 04:28 | <Hixie> | it's one of the most-requested features. |
| 04:28 | <jacobolus> | yes, but I would suggest these are from people who don't know how to draw an ellipse using the existing API |
| 04:28 | <jacobolus> | which is an education problem more than anything |
| 04:28 | <Hixie> | *shrug* |
| 04:28 | <Hixie> | it's easy to add |
| 04:28 | <jacobolus> | which is an education problem more than anything |
| 04:28 | <Hixie> | *shrug* |
| 04:28 | <Hixie> | it's easy to add |
| 04:28 | <jacobolus> | you can also add star shapes, regular polygons, parallelograms with specified skew, heart shapes with various parameters, ad infinitum |
| 04:29 | <jacobolus> | you can also add star shapes, regular polygons, parallelograms with specified skew, heart shapes with various parameters, ad infinitum |
| 04:29 | <jacobolus> | I dunno, anyway, that's not such a big deal |
| 04:29 | <jacobolus> | I dunno, anyway, that's not such a big deal |
| 04:29 | <Hixie> | if we had as many requests for those as for ellipses, you may have a proposal on your hands |
| 04:29 | <Hixie> | but we've never had any requests for those |
| 04:30 | <Hixie> | if we had as many requests for those as for ellipses, you may have a proposal on your hands |
| 04:30 | <Hixie> | but we've never had any requests for those |
| 04:30 | <jacobolus> | I guess what I mean is, a lot of those requests go away if you give people a 5-line code snippet that handles their request |
| 04:31 | <jacobolus> | I guess what I mean is, a lot of those requests go away if you give people a 5-line code snippet that handles their request |
| 04:31 | <jacobolus> | then they can make whatever ellipse API they want |
| 04:31 | <Hixie> | *shrug* |
| 04:31 | <jacobolus> | then they can make whatever ellipse API they want |
| 04:31 | <Hixie> | *shrug* |
| 04:31 | <jacobolus> | addHitRegion proposal seems excessively complex |
| 04:32 | <jacobolus> | addHitRegion proposal seems excessively complex |
| 04:32 | <Hixie> | it solves like a zillion problems with a single function, all things considered i think it's one of the simplest possible solutions one could come up with |
| 04:32 | <Hixie> | it solves like a zillion problems with a single function, all things considered i think it's one of the simplest possible solutions one could come up with |
| 04:32 | <Hixie> | but i'm certainly open to alternative proposals |
| 04:32 | <Hixie> | the wiki page has been up for months waiting for them |
| 04:32 | <jacobolus> | explaining element, id, label, ariaRole, parentID is going to be hard |
| 04:33 | <Hixie> | but i'm certainly open to alternative proposals |
| 04:33 | <Hixie> | the wiki page has been up for months waiting for them |
| 04:33 | <jacobolus> | explaining element, id, label, ariaRole, parentID is going to be hard |
| 04:33 | <jacobolus> | what's the "context's default path"? |
| 04:33 | <jacobolus> | what's the "context's default path"? |
| 04:33 | <Hixie> | see the spec, it's now known as the "current default path" |
| 04:34 | <Hixie> | see the spec, it's now known as the "current default path" |
| 04:35 | <jacobolus> | so if you start drawing a path, that changes the "default path"? |
| 04:35 | <jacobolus> | so if you start drawing a path, that changes the "default path"? |
| 04:35 | <jacobolus> | if you keep on adding to it, does that change the path for the region? |
| 04:35 | <Hixie> | the "current default path" is the only path that exists in the api as implemented today |
| 04:35 | <Hixie> | it's the one that is usud when you call stroke() |
| 04:35 | <jacobolus> | gotcha |
| 04:36 | <jacobolus> | if you keep on adding to it, does that change the path for the region? |
| 04:36 | <Hixie> | the "current default path" is the only path that exists in the api as implemented today |
| 04:36 | <Hixie> | it's the one that is usud when you call stroke() |
| 04:36 | <jacobolus> | gotcha |
| 04:36 | <jacobolus> | so does the region create a copy of that when it's defined? |
| 04:36 | <jacobolus> | or does drawing continually change the region? |
| 04:36 | <jacobolus> | so does the region create a copy of that when it's defined? |
| 04:36 | <jacobolus> | or does drawing continually change the region? |
| 04:36 | <Hixie> | copy, same as stroke() |
| 04:36 | <othermaciej_> | Hixie: is there a way to copy a Path? |
| 04:36 | <jacobolus> | stroke doesn't make a copy of the path. it blits pixels to the screen |
| 04:37 | <Hixie> | copy, same as stroke() |
| 04:37 | <othermaciej_> | Hixie: is there a way to copy a Path? |
| 04:37 | <jacobolus> | stroke doesn't make a copy of the path. it blits pixels to the screen |
| 04:37 | <jacobolus> | after you call stroke, the stroke is no longer a vector object |
| 04:37 | <Hixie> | othermaciej_: create a new one and addFill the old one to the new one |
| 04:37 | <jacobolus> | after you call stroke, the stroke is no longer a vector object |
| 04:37 | <Hixie> | othermaciej_: create a new one and addFill the old one to the new one |
| 04:37 | <Hixie> | othermaciej_: (i was thinking of providing a copy constructor if it's a common operation) |
| 04:37 | <othermaciej_> | well, since Path is mutable, it seems like copying one would be a very common operation |
| 04:38 | <Hixie> | othermaciej_: (i was thinking of providing a copy constructor if it's a common operation) |
| 04:38 | <othermaciej_> | well, since Path is mutable, it seems like copying one would be a very common operation |
| 04:38 | <Hixie> | othermaciej_: makes sense |
| 04:38 | <othermaciej_> | for example, if you pass a Path to a function that may or may not mutate it, and you need the original, then you have to pass a copy |
| 04:38 | <Hixie> | othermaciej_: makes sense |
| 04:38 | <othermaciej_> | for example, if you pass a Path to a function that may or may not mutate it, and you need the original, then you have to pass a copy |
| 04:38 | <Hixie> | jacobolus: same as with hitRegion(), in some implementations. (There's several ways of implementing it, but one is to have a "shadow" canvas with each pixel representing the last hitRegion call on it. This is a technique sometimes used in 3D environments for hit testing.) |
| 04:38 | <Hixie> | othermaciej_: makes sense |
| 04:39 | <Hixie> | jacobolus: same as with hitRegion(), in some implementations. (There's several ways of implementing it, but one is to have a "shadow" canvas with each pixel representing the last hitRegion call on it. This is a technique sometimes used in 3D environments for hit testing.) |
| 04:39 | <Hixie> | othermaciej_: makes sense |
| 04:39 | <Hixie> | othermaciej_: i added new Path(path) copy constructor to the list of things to add in the misc section on the wiki |
| 04:39 | <othermaciej_> | Hixie: I think renaming addFill to addPath and addStroke to addPathByStrokingPath would improve clarity btw, without changing semantics |
| 04:39 | <othermaciej_> | the second name is more verbose, but it is also a much less common operation |
| 04:40 | <Hixie> | othermaciej_: i added new Path(path) copy constructor to the list of things to add in the misc section on the wiki |
| 04:40 | <othermaciej_> | Hixie: I think renaming addFill to addPath and addStroke to addPathByStrokingPath would improve clarity btw, without changing semantics |
| 04:40 | <othermaciej_> | the second name is more verbose, but it is also a much less common operation |
| 04:40 | <Hixie> | othermaciej_: what about the equivalent *Text methods on Path? |
| 04:40 | <Hixie> | othermaciej_: what about the equivalent *Text methods on Path? |
| 04:40 | <Hixie> | othermaciej_: addText and addTextByStrokingPath ? |
| 04:41 | <Hixie> | othermaciej_: addText and addTextByStrokingPath ? |
| 04:41 | <jacobolus> | Hixie: I think transforming the path by the current transformation matrix whenever you call addPath/addStroke leads to some potentially extremely confusing situations |
| 04:42 | <jacobolus> | Hixie: I think transforming the path by the current transformation matrix whenever you call addPath/addStroke leads to some potentially extremely confusing situations |
| 04:42 | <othermaciej_> | adding the outline of the glyph outlines of text is such an unusual operation that it seems odd to me to even have it, but I think it would logically be addPathByStrokingText |
| 04:42 | <jacobolus> | Hixie: given that currently, the shapes of paths end up existing relative to teh whole canvas |
| 04:42 | <jacobolus> | not relative to the transformation |
| 04:42 | <jamesr> | are Paths independent of their canvas or not? |
| 04:42 | <othermaciej_> | adding the outline of the glyph outlines of text is such an unusual operation that it seems odd to me to even have it, but I think it would logically be addPathByStrokingText |
| 04:42 | <jacobolus> | Hixie: given that currently, the shapes of paths end up existing relative to teh whole canvas |
| 04:42 | <jacobolus> | not relative to the transformation |
| 04:42 | <jamesr> | are Paths independent of their canvas or not? |
| 04:42 | <Hixie> | jamesr: yes |
| 04:43 | <Hixie> | jamesr: yes |
| 04:43 | <jacobolus> | so addStroke finds the path you'd get by tracing around the edges of the stroke, not just the original path itself? |
| 04:43 | <jacobolus> | so addStroke finds the path you'd get by tracing around the edges of the stroke, not just the original path itself? |
| 04:43 | <jacobolus> | I agree w/ othermaciej_ re: names |
| 04:43 | <Hixie> | othermaciej_: addPath, addPathByStrokingPath, addText, and addPathByStrokingText? i guess that works |
| 04:43 | <Hixie> | jacobolus: not sure what you mean re the transformation stuff |
| 04:44 | <jacobolus> | I agree w/ othermaciej_ re: names |
| 04:44 | <Hixie> | othermaciej_: addPath, addPathByStrokingPath, addText, and addPathByStrokingText? i guess that works |
| 04:44 | <Hixie> | jacobolus: not sure what you mean re the transformation stuff |
| 04:44 | <jacobolus> | in the current canvas, changing the current transformation does nothing to the current path |
| 04:44 | <Hixie> | if y'all like addPath, addPathByStrokingPath, addText, and addPathByStrokingText i'll use those names |
| 04:44 | <jacobolus> | in the current canvas, changing the current transformation does nothing to the current path |
| 04:44 | <Hixie> | if y'all like addPath, addPathByStrokingPath, addText, and addPathByStrokingText i'll use those names |
| 04:44 | <othermaciej_> | yes, addStroke as currently specified strokes the path, then creates a path such that filling it would be equivalent to stroking the original (i.e. outline of the strokes) |
| 04:44 | <jacobolus> | the transformation and teh path are orthogonal concepts |
| 04:44 | <Hixie> | jacobolus: the transformation is used when creating teh path |
| 04:45 | <othermaciej_> | yes, addStroke as currently specified strokes the path, then creates a path such that filling it would be equivalent to stroking the original (i.e. outline of the strokes) |
| 04:45 | <jacobolus> | the transformation and teh path are orthogonal concepts |
| 04:45 | <Hixie> | jacobolus: same as the transformation on a Path is used when creating the shapes of the Path |
| 04:45 | <Hixie> | jacobolus: the transformation is used when creating teh path |
| 04:45 | <Hixie> | jacobolus: same as the transformation on a Path is used when creating the shapes of the Path |
| 04:45 | <othermaciej_> | btw to do that you need all the details of the line style |
| 04:45 | <jacobolus> | correct. but if you change the transformation before you stroke/fil the path, the path doesn't change |
| 04:45 | <Hixie> | othermaciej_: yeah, that's what i'm working on tomorrow (and earlier today) |
| 04:45 | <jacobolus> | correct. but if you change the transformation before you stroke/fil the path, the path doesn't change |
| 04:45 | <Hixie> | othermaciej_: yeah, that's what i'm working on tomorrow (and earlier today) |
| 04:45 | <Hixie> | jacobolus: right, which makes it impossible to stamp out a bunch of them without redrawing the path. |
| 04:45 | <Hixie> | jacobolus: which is what we're trying to fix by introducing Path objects |
| 04:46 | <Hixie> | jacobolus: right, which makes it impossible to stamp out a bunch of them without redrawing the path. |
| 04:46 | <Hixie> | jacobolus: which is what we're trying to fix by introducing Path objects |
| 04:46 | <jamesr> | Hixie: if you have a Path, you can fill() or stroke() it into any other Path (or context)? |
| 04:46 | <jacobolus> | Hixie: but that's not actually a problem in practice |
| 04:46 | <othermaciej_> | it actually doesn't make sense for Path to have a line style |
| 04:46 | <othermaciej_> | you should pass it in |
| 04:46 | <jacobolus> | Hixie: you just define a function that draws the path |
| 04:46 | <jacobolus> | Hixie: but that's not actually a problem in practice |
| 04:46 | <othermaciej_> | it actually doesn't make sense for Path to have a line style |
| 04:46 | <othermaciej_> | you should pass it in |
| 04:46 | <jacobolus> | Hixie: you just define a function that draws the path |
| 04:46 | <othermaciej_> | because stroking a path will use the context's line style, not the path's (or at least it should) |
| 04:46 | <jacobolus> | Hixie: and then you apply some transformation, call your function, stroke, apply a different transformation, call the function again, stroke |
| 04:46 | <othermaciej_> | so it's misleading for the path to even have a line style, which is used only for the obscure case of adding a path outline to it |
| 04:46 | <Hixie> | othermaciej_: just like stroking a path onto another path will use the target path's line style, sure |
| 04:46 | <jacobolus> | Hixie: this is precisely the idea behind the canvas API, whose abstractions come straight down from PostScript if not earlier |
| 04:46 | <Hixie> | jamesr: yes |
| 04:47 | <othermaciej_> | because stroking a path will use the context's line style, not the path's (or at least it should) |
| 04:47 | <jacobolus> | Hixie: and then you apply some transformation, call your function, stroke, apply a different transformation, call the function again, stroke |
| 04:47 | <othermaciej_> | so it's misleading for the path to even have a line style, which is used only for the obscure case of adding a path outline to it |
| 04:47 | <Hixie> | othermaciej_: just like stroking a path onto another path will use the target path's line style, sure |
| 04:47 | <jacobolus> | Hixie: this is precisely the idea behind the canvas API, whose abstractions come straight down from PostScript if not earlier |
| 04:47 | <Hixie> | jamesr: yes |
| 04:47 | <othermaciej_> | people will think that if you set lineWidth on a Path, then stroking it will use that line width |
| 04:47 | <othermaciej_> | but it won't |
| 04:47 | <othermaciej_> | it's a misleading API |
| 04:47 | <othermaciej_> | people will think that if you set lineWidth on a Path, then stroking it will use that line width |
| 04:47 | <othermaciej_> | but it won't |
| 04:47 | <othermaciej_> | it's a misleading API |
| 04:47 | <jacobolus> | I think adding a line style to a path, instead of having the one on the context, really changes the whole flavor of the canvas API |
| 04:47 | <Hixie> | othermaciej_: happy to entertain alternatives, but this seemed the most consistent with what we have now |
| 04:48 | <jacobolus> | I think adding a line style to a path, instead of having the one on the context, really changes the whole flavor of the canvas API |
| 04:48 | <Hixie> | othermaciej_: happy to entertain alternatives, but this seemed the most consistent with what we have now |
| 04:48 | <othermaciej_> | I think taking the assumption that the Path object should work more or less like the 2DContext itself is not the best design center |
| 04:48 | <jacobolus> | basically, I feel like these changes are being made from an entirely different API aesthetic than the current API, which means that the combination of the two feels very clashy |
| 04:48 | <othermaciej_> | I think taking the assumption that the Path object should work more or less like the 2DContext itself is not the best design center |
| 04:48 | <jacobolus> | basically, I feel like these changes are being made from an entirely different API aesthetic than the current API, which means that the combination of the two feels very clashy |
| 04:48 | <othermaciej_> | that's not how you usually use paths in most graphics APIs that have an object for them |
| 04:48 | <jacobolus> | there's nothing wrong with the new style, but it's confusing to someone who knows the existing canvas API |
| 04:49 | <othermaciej_> | that's not how you usually use paths in most graphics APIs that have an object for them |
| 04:49 | <jacobolus> | there's nothing wrong with the new style, but it's confusing to someone who knows the existing canvas API |
| 04:49 | <othermaciej_> | the 2DContext is the thing that is weird, by copying the odd CG feature of having a context-implicit current path |
| 04:49 | <jacobolus> | and confusing for anyone trying to learn both |
| 04:49 | <jamesr> | well the 'current API aesthetic' is a partial subset of CoreGraphics from ~5 years ago |
| 04:49 | <othermaciej_> | the 2DContext is the thing that is weird, by copying the odd CG feature of having a context-implicit current path |
| 04:49 | <jacobolus> | and confusing for anyone trying to learn both |
| 04:49 | <jamesr> | well the 'current API aesthetic' is a partial subset of CoreGraphics from ~5 years ago |
| 04:49 | <othermaciej_> | but that ends up mixing path operations with context operations |
| 04:49 | <jamesr> | CoreGraphics had the pseudo-OpenGL style state on the context |
| 04:49 | <jacobolus> | jamesr: sure. and comes down from PostScript 25 or whatever years ago |
| 04:49 | <Hixie> | jacobolus: the entire point of the additions is to make it pretty much exactly like the existing api, so i don't really see how you figure that :-) |
| 04:49 | <othermaciej_> | adding context operations to the Path object exacerbates that mistake |
| 04:50 | <othermaciej_> | but that ends up mixing path operations with context operations |
| 04:50 | <jamesr> | CoreGraphics had the pseudo-OpenGL style state on the context |
| 04:50 | <jacobolus> | jamesr: sure. and comes down from PostScript 25 or whatever years ago |
| 04:50 | <Hixie> | jacobolus: the entire point of the additions is to make it pretty much exactly like the existing api, so i don't really see how you figure that :-) |
| 04:50 | <othermaciej_> | adding context operations to the Path object exacerbates that mistake |
| 04:50 | <jacobolus> | jamesr: the current API is really nice to use if you use a functional programming style |
| 04:50 | <jacobolus> | or especially if you use a stack-based language like postscript |
| 04:50 | <jacobolus> | or especially if you use a stack-based language like postscript |
| 04:50 | <Hixie> | othermaciej_: so if we change addFill() to addPath(), that becomes confusingly similar to addPathData(svgPathData), what should we call the latter? |
| 04:50 | <othermaciej_> | svgPathData is the SVG string path syntax? |
| 04:50 | <jacobolus> | Hixie: addPathFromString or similar |
| 04:51 | <Hixie> | othermaciej_: so if we change addFill() to addPath(), that becomes confusingly similar to addPathData(svgPathData), what should we call the latter? |
| 04:51 | <othermaciej_> | svgPathData is the SVG string path syntax? |
| 04:51 | <jacobolus> | Hixie: addPathFromString or similar |
| 04:51 | <Hixie> | othermaciej_: yes |
| 04:51 | <Hixie> | othermaciej_: (though of course that it's svg is an inside baseball factoid) |
| 04:51 | <Hixie> | jacobolus: needs to be something short or it rather defeats the point... |
| 04:52 | <Hixie> | othermaciej_: yes |
| 04:52 | <Hixie> | othermaciej_: (though of course that it's svg is an inside baseball factoid) |
| 04:52 | <Hixie> | jacobolus: needs to be something short or it rather defeats the point... |
| 04:52 | <othermaciej_> | I would have just made that an optional constructor argument |
| 04:52 | <othermaciej_> | I would have just made that an optional constructor argument |
| 04:52 | <othermaciej_> | I think addPathString or addPathSpec or something would be ok |
| 04:52 | <jacobolus> | Hixie: I wouldn’t make it a function on the Path object, but instead make it a function drawing on the context’s path |
| 04:53 | <othermaciej_> | I think addPathString or addPathSpec or something would be ok |
| 04:53 | <jacobolus> | Hixie: I wouldn’t make it a function on the Path object, but instead make it a function drawing on the context’s path |
| 04:53 | <Hixie> | jacobolus: that rather defeats the point of making it possible to use svg strings to build up path objects... |
| 04:54 | <Hixie> | jacobolus: that rather defeats the point of making it possible to use svg strings to build up path objects... |
| 04:54 | <Hixie> | othermaciej_: it's intended that you can chain these to make a single path from different strings |
| 04:54 | <othermaciej_> | I think the constructor approach is best, because the most common use for an SVG path string is to take one string and make one path |
| 04:54 | <Hixie> | othermaciej_: it's intended that you can chain these to make a single path from different strings |
| 04:54 | <othermaciej_> | I think the constructor approach is best, because the most common use for an SVG path string is to take one string and make one path |
| 04:54 | <Hixie> | othermaciej_: addPathString() seems confusing next to addPath() |
| 04:54 | <othermaciej_> | I think combining multiple path specs into a single Path is unlikely |
| 04:54 | <jacobolus> | Hixie: so okay, when you create a Path object from the current default path, I take it whatever the current transformation is gets inverted? |
| 04:54 | <othermaciej_> | sure it should be possible, but you hardly need to optimize for it |
| 04:54 | <jacobolus> | before the Path’s shape is extracted? |
| 04:55 | <Hixie> | othermaciej_: addPathString() seems confusing next to addPath() |
| 04:55 | <othermaciej_> | I think combining multiple path specs into a single Path is unlikely |
| 04:55 | <jacobolus> | Hixie: so okay, when you create a Path object from the current default path, I take it whatever the current transformation is gets inverted? |
| 04:55 | <othermaciej_> | sure it should be possible, but you hardly need to optimize for it |
| 04:55 | <jacobolus> | before the Path’s shape is extracted? |
| 04:55 | <othermaciej_> | var triangle = new Path("M 100 100 L 300 100 L 200 300 z"); |
| 04:55 | <Hixie> | jacobolus: what do you mean "inverted? |
| 04:55 | <Hixie> | er |
| 04:55 | <othermaciej_> | that seems more clear to me than |
| 04:55 | <othermaciej_> | var triangle = new Path("M 100 100 L 300 100 L 200 300 z"); |
| 04:55 | <Hixie> | jacobolus: what do you mean "inverted? |
| 04:55 | <Hixie> | er |
| 04:55 | <othermaciej_> | that seems more clear to me than |
| 04:55 | <Hixie> | jacobolus: what do you mean "create a Path object from the current default path"? |
| 04:55 | <othermaciej_> | var triangle = new Path(); path.addPathData("M 100 100 L 300 100 L 200 300 z"); |
| 04:55 | <othermaciej_> | dang, I got that wrong, but you get the idea |
| 04:55 | <Hixie> | othermaciej_: i guess you can always jsut concatenate the strings together |
| 04:56 | <Hixie> | jacobolus: what do you mean "create a Path object from the current default path"? |
| 04:56 | <othermaciej_> | var triangle = new Path(); path.addPathData("M 100 100 L 300 100 L 200 300 z"); |
| 04:56 | <othermaciej_> | dang, I got that wrong, but you get the idea |
| 04:56 | <Hixie> | othermaciej_: i guess you can always jsut concatenate the strings together |
| 04:56 | <othermaciej_> | Hixie: indeed |
| 04:56 | <Hixie> | alright, i'll move that to a constructor |
| 04:57 | <othermaciej_> | Hixie: indeed |
| 04:57 | <Hixie> | alright, i'll move that to a constructor |
| 04:57 | <jacobolus> | Hixie: oh wait, can you turn the "current default path" into a Path object? |
| 04:57 | <jacobolus> | Hixie: oh wait, can you turn the "current default path" into a Path object? |
| 04:57 | <Hixie> | no |
| 04:57 | <jacobolus> | I see, so this is a one-way deal |
| 04:57 | <jacobolus> | gotcha! |
| 04:58 | <Hixie> | no |
| 04:58 | <jacobolus> | I see, so this is a one-way deal |
| 04:58 | <jacobolus> | gotcha! |
| 04:58 | <jacobolus> | so basically, none of the current canvas APIs for drawing shapes can be used to create Paths |
| 04:58 | <jacobolus> | so basically, none of the current canvas APIs for drawing shapes can be used to create Paths |
| 04:59 | <Hixie> | well it's the exact same api (same interface), so, sure... |
| 04:59 | <jacobolus> | it is? |
| 04:59 | <Hixie> | are you reading the spec? or? |
| 04:59 | <Hixie> | well it's the exact same api (same interface), so, sure... |
| 04:59 | <jacobolus> | it is? |
| 04:59 | <Hixie> | are you reading the spec? or? |
| 04:59 | <jacobolus> | yes |
| 04:59 | <othermaciej_> | Path has a similar interface to Canvas2DContext |
| 04:59 | <Hixie> | has literally has the same interface |
| 04:59 | <othermaciej_> | it inherits from common interfaces for many of the methods |
| 04:59 | <Hixie> | they both implement CanvasPathMethods or something |
| 04:59 | <jacobolus> | oh, I see, http://www.whatwg.org/specs/web-apps/current-work/#canvaspathmethods |
| 05:00 | <jacobolus> | yes |
| 05:00 | <othermaciej_> | Path has a similar interface to Canvas2DContext |
| 05:00 | <Hixie> | has literally has the same interface |
| 05:00 | <othermaciej_> | although I posit that this is actually kind of weird in some cases |
| 05:00 | <othermaciej_> | it inherits from common interfaces for many of the methods |
| 05:00 | <Hixie> | they both implement CanvasPathMethods or something |
| 05:00 | <jacobolus> | oh, I see, http://www.whatwg.org/specs/web-apps/current-work/#canvaspathmethods |
| 05:00 | <othermaciej_> | although I posit that this is actually kind of weird in some cases |
| 05:00 | <jacobolus> | that's really confusing |
| 05:00 | <jacobolus> | that's really confusing |
| 05:01 | <othermaciej_> | well, var path = new Path(); path.moveTo(0, 0); path.lineTo(20, 20); path.lineTo(20, 0); path.closePath(); seems logical enough to me |
| 05:02 | <othermaciej_> | well, var path = new Path(); path.moveTo(0, 0); path.lineTo(20, 20); path.lineTo(20, 0); path.closePath(); seems logical enough to me |
| 05:02 | <jacobolus> | Hixie: but it has no equivalent of context.save() or context.restore() for transformations? |
| 05:02 | <jacobolus> | Hixie: but it has no equivalent of context.save() or context.restore() for transformations? |
| 05:03 | <othermaciej_> | it's the transformation, line style, and text style methods on Path that strike me as weird |
| 05:03 | <othermaciej_> | it's the transformation, line style, and text style methods on Path that strike me as weird |
| 05:04 | <Hixie> | jacobolus: it has a method so you an reset the transform to whatever you want |
| 05:04 | <jacobolus> | Hixie: yes, but there's no stack of them. which makes it dramatically less powerful than the context version |
| 05:05 | <Hixie> | jacobolus: it has a method so you an reset the transform to whatever you want |
| 05:05 | <jacobolus> | Hixie: yes, but there's no stack of them. which makes it dramatically less powerful than the context version |
| 05:05 | <jacobolus> | unless you keep track of the transform manually |
| 05:05 | <Hixie> | well yeah, it's not like you're going to be doing much with them |
| 05:05 | <jacobolus> | unless you keep track of the transform manually |
| 05:05 | <Hixie> | well yeah, it's not like you're going to be doing much with them |
| 05:05 | <jamesr> | i think it'd make more sense if they weren't there and the only time a xform applied was when you were plopping them into a context's default path |
| 05:05 | <jamesr> | or if we had a separate notion of a transform stack, perhaps |
| 05:05 | <othermaciej_> | that is certainly what seems natural to me |
| 05:06 | <jamesr> | i think it'd make more sense if they weren't there and the only time a xform applied was when you were plopping them into a context's default path |
| 05:06 | <jamesr> | or if we had a separate notion of a transform stack, perhaps |
| 05:06 | <othermaciej_> | that is certainly what seems natural to me |
| 05:06 | <Hixie> | jamesr: how would you create a path that had another path stamped in four locations? |
| 05:06 | <othermaciej_> | that plus an ability to one-shot apply a transform (either to a whole path, or it would return a new transformed path) |
| 05:06 | <jacobolus> | the only things here that are really adding new capability beyond what's currently possible are dashed lines and extracting the current path as a saved "region" |
| 05:06 | <Hixie> | jamesr: how would you create a path that had another path stamped in four locations? |
| 05:06 | <othermaciej_> | that plus an ability to one-shot apply a transform (either to a whole path, or it would return a new transformed path) |
| 05:06 | <jacobolus> | the only things here that are really adding new capability beyond what's currently possible are dashed lines and extracting the current path as a saved "region" |
| 05:06 | <jacobolus> | the Path objects add a lot of complexity, and maybe provide something that's more intuitive, but don't really add power beyond what's there now |
| 05:06 | <Hixie> | othermaciej_: i guess we could have a method that takes an SVGMatrix and transforms the path to it |
| 05:07 | <jacobolus> | the Path objects add a lot of complexity, and maybe provide something that's more intuitive, but don't really add power beyond what's there now |
| 05:07 | <Hixie> | othermaciej_: i guess we could have a method that takes an SVGMatrix and transforms the path to it |
| 05:07 | <othermaciej_> | you can store a path and draw it repeatedly |
| 05:07 | <othermaciej_> | that's the main power that is added |
| 05:07 | <jamesr> | Hixie: subPath = new Path(); parent = new Path(); parent.fillPath(subPath, transformA); parent.fillPath(subPath, transformB); parent.fillPath(subPath, transformC); parent.fillPath(subPath, transformD); |
| 05:07 | <Hixie> | othermaciej_: not sure what we'd do for the line styles though |
| 05:07 | <othermaciej_> | this is pretty useful |
| 05:07 | <othermaciej_> | you can store a path and draw it repeatedly |
| 05:07 | <othermaciej_> | that's the main power that is added |
| 05:07 | <jamesr> | Hixie: subPath = new Path(); parent = new Path(); parent.fillPath(subPath, transformA); parent.fillPath(subPath, transformB); parent.fillPath(subPath, transformC); parent.fillPath(subPath, transformD); |
| 05:07 | <Hixie> | othermaciej_: not sure what we'd do for the line styles though |
| 05:07 | <othermaciej_> | this is pretty useful |
| 05:07 | <jacobolus> | you can currently define a function that draws a path, and then call it repeatedly |
| 05:07 | <jamesr> | or more likely manipulate a single transform between each fill..() |
| 05:07 | <jacobolus> | which is just as useful |
| 05:07 | <Hixie> | jamesr: yeah, that makes sense |
| 05:07 | <jacobolus> | and just about as fast, since the slow part is typically the fill/stroke, rather than creating the lines themselves |
| 05:08 | <jacobolus> | you can currently define a function that draws a path, and then call it repeatedly |
| 05:08 | <jamesr> | or more likely manipulate a single transform between each fill..() |
| 05:08 | <jacobolus> | which is just as useful |
| 05:08 | <Hixie> | jamesr: yeah, that makes sense |
| 05:08 | <jacobolus> | and just about as fast, since the slow part is typically the fill/stroke, rather than creating the lines themselves |
| 05:08 | <othermaciej_> | Hixie: CG passes the line style parameters individually, but one could imagine having a LineStyle object which is passed only when doing the "stroke the stroke outline" thing |
| 05:08 | <Hixie> | i guess |
| 05:08 | <Hixie> | ok |
| 05:08 | <othermaciej_> | Hixie: CG passes the line style parameters individually, but one could imagine having a LineStyle object which is passed only when doing the "stroke the stroke outline" thing |
| 05:08 | <Hixie> | i guess |
| 05:08 | <Hixie> | ok |
| 05:08 | <Hixie> | i shall investigate this further tomorrow |
| 05:08 | <jamesr> | Hixie: sent you some dated canvas 2d feedback via gchat |
| 05:08 | <jamesr> | will try to get the author of that to send to WHATWG |
| 05:08 | <Hixie> | jamesr: k |
| 05:09 | <Hixie> | i shall investigate this further tomorrow |
| 05:09 | <jacobolus> | dashed lines are a really nice addition though! |
| 05:09 | <jamesr> | Hixie: sent you some dated canvas 2d feedback via gchat |
| 05:09 | <jamesr> | will try to get the author of that to send to WHATWG |
| 05:09 | <Hixie> | jamesr: k |
| 05:09 | <jacobolus> | dashed lines are a really nice addition though! |
| 05:09 | <jacobolus> | doing those manually is a huge pain |
| 05:09 | <othermaciej_> | interestingly, the CG AddPath operation lets you pass a transform |
| 05:09 | <othermaciej_> | along the lines of what jamesr suggests |
| 05:09 | <othermaciej_> | interestingly, the CG AddPath operation lets you pass a transform |
| 05:09 | <othermaciej_> | along the lines of what jamesr suggests |
| 05:09 | <jacobolus> | and regions are nice too, though the API seems complex |
| 05:10 | <jacobolus> | and regions are nice too, though the API seems complex |
| 05:10 | <jamesr> | it might also be nice to be able to map the points on a Path through some transform in-place |
| 05:11 | <jamesr> | it might also be nice to be able to map the points on a Path through some transform in-place |
| 05:11 | <jamesr> | although i guess that's just a matter of making a new path and fillPath()ing it |
| 05:11 | <jamesr> | although i guess that's just a matter of making a new path and fillPath()ing it |
| 05:11 | <jamesr> | oh, that'd just be path.addFill(path, transform) |
| 05:11 | <jacobolus> | I guess one nice thing about not making much that's strictly impossible now is that it'll be possible to create a polyfill to do everything but tracing strokes and dashed strokes, and it'll work in all the current canvas implementations |
| 05:12 | <jamesr> | oh, that'd just be path.addFill(path, transform) |
| 05:12 | <jacobolus> | I guess one nice thing about not making much that's strictly impossible now is that it'll be possible to create a polyfill to do everything but tracing strokes and dashed strokes, and it'll work in all the current canvas implementations |
| 05:12 | <jamesr> | wait nope, misread the algo. anyway, that's probably less |
| 05:12 | <jamesr> | wait nope, misread the algo. anyway, that's probably less |
| 05:12 | <othermaciej_> | NSBezierPath has a transformUsingAffineTransform: method |
| 05:12 | <othermaciej_> | but no CTM |
| 05:13 | <othermaciej_> | NSBezierPath has a transformUsingAffineTransform: method |
| 05:13 | <othermaciej_> | but no CTM |
| 05:13 | <jacobolus> | Hixie: while we’re adding stuff, can we add a 4-by-4 transformation matrix, compatible with 3d css animations? |
| 05:13 | <Hixie> | i'm just gonna use SVGMatrix, so, speak to them |
| 05:13 | <jacobolus> | that one would be actually really neat |
| 05:13 | <jamesr> | SVGMatrix is 2x3 |
| 05:14 | <jacobolus> | Hixie: while we’re adding stuff, can we add a 4-by-4 transformation matrix, compatible with 3d css animations? |
| 05:14 | <Hixie> | i'm just gonna use SVGMatrix, so, speak to them |
| 05:14 | <jacobolus> | that one would be actually really neat |
| 05:14 | <jamesr> | SVGMatrix is 2x3 |
| 05:14 | <jacobolus> | 2 by 3 is really annoying, because it’s impossible to do any perspective |
| 05:14 | <jacobolus> | 2 by 3 is really annoying, because it’s impossible to do any perspective |
| 05:14 | <jacobolus> | even 3 by 3 is way more useful |
| 05:14 | <jamesr> | that might be old |
| 05:14 | <othermaciej_> | perspective transforms with a 2D API do not make sense to me |
| 05:14 | <jamesr> | i don't think perspective is a good idea for canvas 2d |
| 05:14 | <jamesr> | jinx |
| 05:15 | <jacobolus> | even 3 by 3 is way more useful |
| 05:15 | <jamesr> | that might be old |
| 05:15 | <othermaciej_> | perspective transforms with a 2D API do not make sense to me |
| 05:15 | <jacobolus> | why? |
| 05:15 | <jamesr> | i don't think perspective is a good idea for canvas 2d |
| 05:15 | <jamesr> | jinx |
| 05:15 | <jacobolus> | why? |
| 05:15 | <jamesr> | but we need some 4x4 for CSSOM for 3d transforms |
| 05:15 | <jacobolus> | for someone who doesn't want it, it's invisible |
| 05:15 | <jamesr> | but we need some 4x4 for CSSOM for 3d transforms |
| 05:15 | <jacobolus> | for someone who doesn't want it, it's invisible |
| 05:15 | <jacobolus> | for someone who does, there's lots of cool fake-3d stuff that can be done w/ perspective transforms |
| 05:15 | <jacobolus> | or things like stitching photos together in panoramas |
| 05:15 | <othermaciej_> | when you stroke a path with a perspective transform in effect, does the line thickness change along the path? |
| 05:16 | <jacobolus> | for someone who does, there's lots of cool fake-3d stuff that can be done w/ perspective transforms |
| 05:16 | <jacobolus> | or things like stitching photos together in panoramas |
| 05:16 | <othermaciej_> | when you stroke a path with a perspective transform in effect, does the line thickness change along the path? |
| 05:16 | <jacobolus> | ah, that's fair I guess |
| 05:16 | <jacobolus> | ah, that's fair I guess |
| 05:17 | <jacobolus> | would have to be relative to some origin point, which I suppose would be fairly arbitrary |
| 05:17 | <othermaciej_> | if you follow that question to its logical conclusion, you will likely find that either answer will result in some part of the API not making sense |
| 05:17 | <jacobolus> | would have to be relative to some origin point, which I suppose would be fairly arbitrary |
| 05:17 | <othermaciej_> | if you follow that question to its logical conclusion, you will likely find that either answer will result in some part of the API not making sense |
| 05:17 | <jamesr> | mr doob has some nifty demos using existing APIs, but it's all done in JS-land. i think in general people doing 3d stuff should either stick to 3d APIs or do all the math themselves |
| 05:17 | <jamesr> | it's hard to go halfway in an API and have it still make sense, and i don't think anyone wants to go all the way for canvas 2d |
| 05:18 | <jamesr> | mr doob has some nifty demos using existing APIs, but it's all done in JS-land. i think in general people doing 3d stuff should either stick to 3d APIs or do all the math themselves |
| 05:18 | <jamesr> | it's hard to go halfway in an API and have it still make sense, and i don't think anyone wants to go all the way for canvas 2d |
| 05:19 | <jacobolus> | othermaciej_, jamesr: at the same time, you can't actually get a stroke that changes width along its edge w/ the current APIs, meaning that it's impossible to do many types of nifty demos w/ the current APIs unless you manually implement all the strokes as fills in JS-land |
| 05:19 | <jacobolus> | othermaciej_, jamesr: at the same time, you can't actually get a stroke that changes width along its edge w/ the current APIs, meaning that it's impossible to do many types of nifty demos w/ the current APIs unless you manually implement all the strokes as fills in JS-land |
| 05:19 | <jacobolus> | [along a straight edge that is] |
| 05:19 | <othermaciej_> | you would have to calculate the outline of the stroke and fill it |
| 05:20 | <jacobolus> | [along a straight edge that is] |
| 05:20 | <othermaciej_> | to do fake 3D with 2D APIs |
| 05:20 | <othermaciej_> | you would have to calculate the outline of the stroke and fill it |
| 05:20 | <othermaciej_> | to do fake 3D with 2D APIs |
| 05:20 | <jacobolus> | right. "manually implement all the strokes as fills" |
| 05:20 | <jacobolus> | right. "manually implement all the strokes as fills" |
| 05:20 | <othermaciej_> | btw, supporting perspective transforms is not invisible to those who do not use it |
| 05:20 | <othermaciej_> | it imposes memory/perf cost |
| 05:20 | <othermaciej_> | btw, supporting perspective transforms is not invisible to those who do not use it |
| 05:20 | <othermaciej_> | it imposes memory/perf cost |
| 05:20 | <othermaciej_> | because your representation of a transform has to be 4x4 instead of 2x3 |
| 05:20 | <jacobolus> | really? I thought graphics hardware was designed for multiplying square matrices! |
| 05:20 | <jacobolus> | othermaciej_: no, 3 by 3 |
| 05:21 | <othermaciej_> | because your representation of a transform has to be 4x4 instead of 2x3 |
| 05:21 | <jacobolus> | really? I thought graphics hardware was designed for multiplying square matrices! |
| 05:21 | <jacobolus> | othermaciej_: no, 3 by 3 |
| 05:21 | <othermaciej_> | an affine transform can be stored as a 2x3 matrix |
| 05:21 | <othermaciej_> | and often is |
| 05:21 | <jacobolus> | yes, and a perspective transform can be stored as a 3x3 matrix |
| 05:21 | <othermaciej_> | an affine transform can be stored as a 2x3 matrix |
| 05:21 | <othermaciej_> | and often is |
| 05:21 | <jacobolus> | yes, and a perspective transform can be stored as a 3x3 matrix |
| 05:21 | <jacobolus> | I'm pretty sure whatever low-level API is being used is multiplying 3x3 matrices anyway |
| 05:21 | <jamesr> | i doubt that |
| 05:21 | <othermaciej_> | you can ignore the [0, 0, 1] row |
| 05:22 | <jacobolus> | I'm pretty sure whatever low-level API is being used is multiplying 3x3 matrices anyway |
| 05:22 | <jamesr> | i doubt that |
| 05:22 | <othermaciej_> | I do not believe 3x3 is sufficient even for 3D affine transforms, let alone perspective |
| 05:22 | <othermaciej_> | you can ignore the [0, 0, 1] row |
| 05:22 | <othermaciej_> | I do not believe 3x3 is sufficient even for 3D affine transforms, let alone perspective |
| 05:22 | <jacobolus> | othermaciej_: if you replace the 0's w/ something else, then you get a perspective transform |
| 05:22 | <jacobolus> | othermaciej_: if you replace the 0's w/ something else, then you get a perspective transform |
| 05:22 | <jamesr> | jacobolus: i'd want to see some evidence of that (and i work on these low-level APIs and the interfaces to them) |
| 05:22 | <jacobolus> | this is called "homogeneous coordinates" |
| 05:22 | <jamesr> | jacobolus: i'd want to see some evidence of that (and i work on these low-level APIs and the interfaces to them) |
| 05:22 | <jacobolus> | this is called "homogeneous coordinates" |
| 05:22 | <jacobolus> | jamesr: well I don't really know. I should go look at the implementations sometime |
| 05:22 | <jacobolus> | jamesr: but the whole point of using a matrix is so that you can just use matrix multiplications |
| 05:23 | <jacobolus> | jamesr: well I don't really know. I should go look at the implementations sometime |
| 05:23 | <jacobolus> | jamesr: but the whole point of using a matrix is so that you can just use matrix multiplications |
| 05:23 | <jamesr> | and a matrix multiplication is a bunch of component multiplications. if you don't have some of those components, you can ignore 'em |
| 05:23 | <jamesr> | and a matrix multiplication is a bunch of component multiplications. if you don't have some of those components, you can ignore 'em |
| 05:23 | <jacobolus> | yeah, but they aren't ignored at the openGL layer I don't think |
| 05:24 | <jacobolus> | yeah, but they aren't ignored at the openGL layer I don't think |
| 05:24 | <jamesr> | if i was working on an OpenGL canvas 2d backend, i'd pass a 2x3 matrix in as a uniform or buffer of 6 floats |
| 05:24 | <jamesr> | and if i had to pass them in as 9 floats i'd be sad about the extra transfer space and multiplications in whichever shader it ran in |
| 05:25 | <jamesr> | if i was working on an OpenGL canvas 2d backend, i'd pass a 2x3 matrix in as a uniform or buffer of 6 floats |
| 05:25 | <jamesr> | and if i had to pass them in as 9 floats i'd be sad about the extra transfer space and multiplications in whichever shader it ran in |
| 05:25 | <jacobolus> | I thought modern graphics hardware could do some ungodly number of matrix multiplications per second |
| 05:25 | <jamesr> | true, but it's still not infinity |
| 05:26 | <jacobolus> | I thought modern graphics hardware could do some ungodly number of matrix multiplications per second |
| 05:26 | <jamesr> | and you have to store those numbers and transfer them |
| 05:26 | <jamesr> | true, but it's still not infinity |
| 05:26 | <jamesr> | and you have to store those numbers and transfer them |
| 05:26 | <jacobolus> | far outstripping the actual speed of drawing stuff to the screen |
| 05:26 | <othermaciej_> | lemme put it this way; in WebKit, a 2D affine transform is 6 doubles, and a 3d perspective transform is 16 doubles |
| 05:26 | <jamesr> | depends on the scene |
| 05:26 | <jacobolus> | the number of transformation matrices you use in a canvas is tiny |
| 05:26 | <jacobolus> | far outstripping the actual speed of drawing stuff to the screen |
| 05:26 | <jamesr> | depends on the scene |
| 05:26 | <othermaciej_> | lemme put it this way; in WebKit, a 2D affine transform is 6 doubles, and a 3d perspective transform is 16 doubles |
| 05:26 | <jamesr> | depends on the scene |
| 05:26 | <jacobolus> | the number of transformation matrices you use in a canvas is tiny |
| 05:26 | <jamesr> | depends on the scene |
| 05:26 | <jamesr> | you can definitely be vertex-shader bound |
| 05:26 | <jacobolus> | othermaciej_: sure, but it could be 9 doubles if you wanted |
| 05:26 | <othermaciej_> | while it is remotely possible that all the graphics experts who work on WebKit overlooked a huge way to save storage, that seems unlikely to me |
| 05:26 | <jamesr> | or memory bandwidth bound if you have a lot of geometry and lots of matrices |
| 05:27 | <jamesr> | you can definitely be vertex-shader bound |
| 05:27 | <jacobolus> | othermaciej_: sure, but it could be 9 doubles if you wanted |
| 05:27 | <othermaciej_> | while it is remotely possible that all the graphics experts who work on WebKit overlooked a huge way to save storage, that seems unlikely to me |
| 05:27 | <jamesr> | or memory bandwidth bound if you have a lot of geometry and lots of matrices |
| 05:27 | <jamesr> | 3x3 is a big cost compared to the payoff |
| 05:27 | <othermaciej_> | but if it is true, I should file a bug |
| 05:27 | <jamesr> | 3x3 is a big cost compared to the payoff |
| 05:27 | <othermaciej_> | but if it is true, I should file a bug |
| 05:28 | <jacobolus> | othermaciej_: with strictly equivalent power in terms of 2d, but somewhat less obvious math to do to move things around in 3d space, and no ability to do 3-d perspective transforms (which I haven’t ever actually seen used but would be cool) |
| 05:28 | <jacobolus> | othermaciej_: with strictly equivalent power in terms of 2d, but somewhat less obvious math to do to move things around in 3d space, and no ability to do 3-d perspective transforms (which I haven’t ever actually seen used but would be cool) |
| 05:29 | <jacobolus> | othermaciej_: it's definitely not worth it to use 3x3 matrix if you're actually dealing w/ 3d space, if only because figuring out what the numbers mean in terms of the 3d space is much less clear, and because there aren't obvious answers w/r/t questions like what is in front of what |
| 05:29 | <jacobolus> | othermaciej_: it's definitely not worth it to use 3x3 matrix if you're actually dealing w/ 3d space, if only because figuring out what the numbers mean in terms of the 3d space is much less clear, and because there aren't obvious answers w/r/t questions like what is in front of what |
| 05:29 | <jacobolus> | if you use a 3x4 matrix, you can specify affine transform in 3d + translation |
| 05:30 | <jacobolus> | if you use a 3x4 matrix, you can specify affine transform in 3d + translation |
| 05:30 | <jacobolus> | and you just pass 4x4 matrix, because you might as well at that point, but that last row is typically not used |
| 05:30 | <jacobolus> | and you just pass 4x4 matrix, because you might as well at that point, but that last row is typically not used |
| 05:30 | <jacobolus> | [but you could use the last row to do some really weird fun stuff!] |
| 05:30 | <jamesr> | for 3d css we have to handle real perspective |
| 05:31 | <jacobolus> | [but you could use the last row to do some really weird fun stuff!] |
| 05:31 | <jamesr> | so 4x4 is pretty much required |
| 05:31 | <jamesr> | for 3d css we have to handle real perspective |
| 05:31 | <jamesr> | so 4x4 is pretty much required |
| 05:31 | <jacobolus> | jamesr: you can do precisely the same perspective transformations with a 3x3 matrix. it's just harder to relate to some concrete 3-d scene |
| 05:32 | <jacobolus> | jamesr: you can do precisely the same perspective transformations with a 3x3 matrix. it's just harder to relate to some concrete 3-d scene |
| 05:32 | <jacobolus> | and so if you want to rotate by some amount in your existing 3d scene, say, figuring out the right matrix to use is more expensive arithmetic than if you use the 4x4 matrix |
| 05:32 | <jacobolus> | where it's completely obvious |
| 05:33 | <jacobolus> | and so if you want to rotate by some amount in your existing 3d scene, say, figuring out the right matrix to use is more expensive arithmetic than if you use the 4x4 matrix |
| 05:33 | <jacobolus> | where it's completely obvious |
| 05:34 | <jacobolus> | anyhow, it would be kind of neat to get faux-3-d in canvas, but it's not strictly necessary |
| 05:34 | <jacobolus> | anyhow, it would be kind of neat to get faux-3-d in canvas, but it's not strictly necessary |
| 05:35 | <jacobolus> | it would also be really nice to have some fast functions for doing various matrix math implemented in all the browsers |
| 05:35 | <jacobolus> | it would also be really nice to have some fast functions for doing various matrix math implemented in all the browsers |
| 05:35 | <jacobolus> | [anyhow, sorry to have somewhat derailed the conversation. wasn't trying to do that :)] |
| 05:36 | <jacobolus> | [anyhow, sorry to have somewhat derailed the conversation. wasn't trying to do that :)] |
| 05:39 | <jamesr> | i think having efficient implementations of common matrix ops falls under the various matrix API proposals floating 'around |
| 05:40 | <jamesr> | i think having efficient implementations of common matrix ops falls under the various matrix API proposals floating 'around |
| 05:40 | <jacobolus> | othermaciej_, jamesr: here's an example of using a functional-code-style approach to the canvas http://jsfiddle.net/x9rUN/2/ |
| 05:40 | <jacobolus> | othermaciej_, jamesr: here's an example of using a functional-code-style approach to the canvas http://jsfiddle.net/x9rUN/2/ |
| 05:40 | <jacobolus> | [albeit a fairly trivial one] |
| 05:41 | <jacobolus> | [albeit a fairly trivial one] |
| 06:28 | <othermaciej_> | jacobolus: neat, though not really what I think of as "functional" |
| 06:29 | <othermaciej_> | jacobolus: neat, though not really what I think of as "functional" |
| 06:29 | <othermaciej_> | I would expect a functional approach to be stateless and side-effect free |
| 06:30 | <othermaciej_> | I would expect a functional approach to be stateless and side-effect free |
| 06:37 | <jacobolus> | othermaciej_: well, "functional" |
| 06:38 | <jacobolus> | othermaciej_: well, "functional" |
| 06:38 | <jacobolus> | othermaciej_: really more like "how do you approximate the kind of abstraction you'd build in postscript in javascript" |
| 06:38 | <jacobolus> | othermaciej_: really more like "how do you approximate the kind of abstraction you'd build in postscript in javascript" |
| 06:38 | <jacobolus> | not sure what a right name is for that |
| 06:39 | <jacobolus> | not sure what a right name is for that |
| 06:53 | <jacobolus> | the key point though is that by using higher-order functions, passing around functions as first-class objects, and saving state in the context stack rather than explicitly in our own objects, we can make some very nice clean abstractions |
| 06:53 | <jacobolus> | the key point though is that by using higher-order functions, passing around functions as first-class objects, and saving state in the context stack rather than explicitly in our own objects, we can make some very nice clean abstractions |
| 06:53 | <jacobolus> | maybe "functional" doesn't quite work as a word for that, but hey |
| 06:54 | <jacobolus> | maybe "functional" doesn't quite work as a word for that, but hey |
| 07:24 | zcorpan | updated html5-diff |
| 07:25 | zcorpan | updated html5-diff |
| 07:57 | <annevk> | "which is the number I should phone" Dutch people on the lounge and speaking loudly :/ |
| 07:58 | <annevk> | "which is the number I should phone" Dutch people on the lounge and speaking loudly :/ |
| 07:58 | <annevk> | (they're trying to talk in English) |
| 07:58 | <annevk> | (they're trying to talk in English) |
| 07:59 | <annevk> | momentarily forgot I could listen to some music instead |
| 07:59 | <annevk> | problem solved |
| 07:59 | <annevk> | momentarily forgot I could listen to some music instead |
| 07:59 | <annevk> | problem solved |
| 08:06 | <hsivonen> | MikeSmith: emitting such a message would make a lot of sense |
| 08:06 | <MikeSmith> | OK |
| 08:06 | <hsivonen> | (the build script pointing people to #whatwg that is) |
| 08:06 | <hsivonen> | MikeSmith: emitting such a message would make a lot of sense |
| 08:06 | <MikeSmith> | OK |
| 08:06 | <hsivonen> | (the build script pointing people to #whatwg that is) |
| 08:06 | <MikeSmith> | yeah |
| 08:07 | <MikeSmith> | yeah |
| 08:07 | <MikeSmith> | hsivonen: btw I wrote a patch for jing that adds HTML support |
| 08:07 | <MikeSmith> | hsivonen: btw I wrote a patch for jing that adds HTML support |
| 08:07 | <MikeSmith> | I wonder if you think it's a good idea or not |
| 08:07 | <MikeSmith> | using the validator.nu parser of course |
| 08:08 | <MikeSmith> | I wonder if you think it's a good idea or not |
| 08:08 | <MikeSmith> | using the validator.nu parser of course |
| 08:08 | <MikeSmith> | enabled through a new -h switch for the cli, and through a settable property flag in the code |
| 08:09 | <MikeSmith> | enabled through a new -h switch for the cli, and through a settable property flag in the code |
| 08:11 | <annevk> | WHATWG Weekly: path objects, ellipse support, SVG paths |
| 08:11 | <annevk> | anything else? |
| 08:11 | <annevk> | WHATWG Weekly: path objects, ellipse support, SVG paths |
| 08:11 | <annevk> | anything else? |
| 08:13 | <hsivonen> | MikeSmith: cool. did it get accepted to upstream? |
| 08:13 | <MikeSmith> | hsivonen: have not proposed it to James yet |
| 08:13 | <MikeSmith> | wanted to get your opinion first |
| 08:14 | <hsivonen> | MikeSmith: cool. did it get accepted to upstream? |
| 08:14 | <MikeSmith> | hsivonen: have not proposed it to James yet |
| 08:14 | <MikeSmith> | wanted to get your opinion first |
| 08:14 | <MikeSmith> | about whether you think's helpful and worth pursuing |
| 08:14 | <MikeSmith> | about whether you think's helpful and worth pursuing |
| 08:14 | <MikeSmith> | *think it's |
| 08:15 | <MikeSmith> | *think it's |
| 08:15 | <MikeSmith> | we obviously don't need it for the validator.nu branch |
| 08:15 | <MikeSmith> | we obviously don't need it for the validator.nu branch |
| 08:15 | <MikeSmith> | so yeah the plan would be to get it landed upstream |
| 08:15 | <annevk> | seems I'm not going to post this before takeoff |
| 08:15 | <MikeSmith> | so yeah the plan would be to get it landed upstream |
| 08:15 | <annevk> | seems I'm not going to post this before takeoff |
| 08:16 | <MikeSmith> | annevk: you work on it when you land? how many hours from now? |
| 08:16 | <MikeSmith> | annevk: you work on it when you land? how many hours from now? |
| 08:17 | <annevk> | two hours more or less |
| 08:17 | <MikeSmith> | ok |
| 08:17 | <annevk> | should be home in less than four, ideally so it's not a big deal |
| 08:17 | <annevk> | two hours more or less |
| 08:17 | <MikeSmith> | ok |
| 08:17 | <annevk> | should be home in less than four, ideally so it's not a big deal |
| 08:17 | <hsivonen> | MikeSmith: I think it could be useful for the command-line Jing tool |
| 08:17 | <MikeSmith> | annevk: in the mean time will try to catch up with mail and see if there's anything I can suggest adding |
| 08:17 | <hsivonen> | MikeSmith: I'm not a user of the command-line Jing tool, though, so I might be wrong |
| 08:18 | <hsivonen> | MikeSmith: I think it could be useful for the command-line Jing tool |
| 08:18 | <MikeSmith> | annevk: in the mean time will try to catch up with mail and see if there's anything I can suggest adding |
| 08:18 | <hsivonen> | MikeSmith: I'm not a user of the command-line Jing tool, though, so I might be wrong |
| 08:18 | <hsivonen> | annevk: were you at SXSW? |
| 08:18 | <hsivonen> | annevk: were you at SXSW? |
| 08:19 | <MikeSmith> | hsivonen: could it be useful for other users of the API? e.g., the epubcheck tool uses the API, I think |
| 08:19 | <MikeSmith> | hsivonen: could it be useful for other users of the API? e.g., the epubcheck tool uses the API, I think |
| 08:21 | <annevk> | hsivonen: no in Oslo |
| 08:21 | <annevk> | added the encoding/decoding stuff btw |
| 08:22 | <annevk> | hsivonen: no in Oslo |
| 08:22 | <annevk> | added the encoding/decoding stuff btw |
| 08:28 | <hsivonen> | MikeSmith: what's "the API"? |
| 08:29 | <hsivonen> | MikeSmith: what's "the API"? |
| 08:29 | <MikeSmith> | the Jing validation API |
| 08:29 | <MikeSmith> | mode/rngvalidate or whatever it is |
| 08:29 | <MikeSmith> | the Jing validation API |
| 08:29 | <MikeSmith> | mode/rngvalidate or whatever it is |
| 08:29 | <MikeSmith> | ValidationDriver |
| 08:30 | <MikeSmith> | ValidationDriver |
| 08:30 | <MikeSmith> | class |
| 08:31 | <MikeSmith> | class |
| 08:40 | <zcorpan> | MikeSmith: i tried validating the whatwg stylesheet and filed a few bugs on the css validator |
| 08:40 | <MikeSmith> | zcorpan: excellent, thanks |
| 08:40 | <zcorpan> | MikeSmith: i tried validating the whatwg stylesheet and filed a few bugs on the css validator |
| 08:40 | <MikeSmith> | zcorpan: excellent, thanks |
| 08:40 | <zcorpan> | MikeSmith: and whined about the spec language around unquoted font family names *again* |
| 08:40 | <MikeSmith> | heh |
| 08:41 | <zcorpan> | MikeSmith: and whined about the spec language around unquoted font family names *again* |
| 08:41 | <MikeSmith> | heh |
| 08:42 | <zcorpan> | the css wg have taught web authors the mantra "if there's whitespace in the font family name, i must quote it", so they would quote "times new roman" but not quote "456bereast" |
| 08:42 | <zcorpan> | even though the former works unquoted and the latter doesn't |
| 08:42 | <zcorpan> | the css wg have taught web authors the mantra "if there's whitespace in the font family name, i must quote it", so they would quote "times new roman" but not quote "456bereast" |
| 08:42 | <zcorpan> | even though the former works unquoted and the latter doesn't |
| 08:46 | <zcorpan> | i guess this is a topic matjas could write about |
| 08:46 | <zcorpan> | i guess this is a topic matjas could write about |
| 08:46 | <matjas> | I’m intrigued (also: mind = blown) |
| 08:47 | <matjas> | I’m intrigued (also: mind = blown) |
| 08:51 | <zcorpan> | matjas: i think mothereffin css escapes applies to unquoted font family names, except unquoted font family names can have several identifiers that are turned into a string by joining them (after unescaping) with a space |
| 08:52 | <zcorpan> | matjas: i think mothereffin css escapes applies to unquoted font family names, except unquoted font family names can have several identifiers that are turned into a string by joining them (after unescaping) with a space |
| 08:52 | <zcorpan> | matjas: since id and class also are identifiers |
| 08:52 | <zcorpan> | matjas: since id and class also are identifiers |
| 08:54 | <zcorpan> | that and keywords aren't allowed as unquoted font family names |
| 08:55 | <matjas> | hah, thanks for doing all the research for me :) |
| 08:56 | <matjas> | hah, thanks for doing all the research for me :) |
| 08:56 | <zcorpan> | that was off the top of my head, i might be lying :-P |
| 08:57 | <zcorpan> | that was off the top of my head, i might be lying :-P |
| 08:57 | <jgraham> | Experience suggests that the top of zcorpan's head is quite a reliable source of information |
| 08:57 | <jgraham> | Experience suggests that the top of zcorpan's head is quite a reliable source of information |
| 08:57 | <zcorpan> | heh |
| 08:58 | <zcorpan> | heh |
| 08:58 | <matjas> | data:text/html,<style>:root { font-family: \63 omic\ sans\ ms, sans-serif; }%E2%80%8B</style>lolwat |
| 08:58 | <matjas> | nice |
| 08:58 | <matjas> | data:text/html,<style>:root { font-family: \63 omic\ sans\ ms, sans-serif; }%E2%80%8B</style>lolwat |
| 08:58 | <matjas> | nice |
| 08:59 | <matjas> | but… data:text/html,<style>:root { font-family: \63 omic\ sans\ ms, sans-serif; }%E2%80%8B</style>lolwat is rendered in sans-serif |
| 08:59 | <matjas> | but… data:text/html,<style>:root { font-family: \63 omic\ sans\ ms, sans-serif; }%E2%80%8B</style>lolwat is rendered in sans-serif |
| 09:01 | <zcorpan> | pasted the wrong thing? or what's the difference? |
| 09:01 | <zcorpan> | pasted the wrong thing? or what's the difference? |
| 09:01 | <zcorpan> | also, you don't need to escape the spaces :-) |
| 09:02 | <zcorpan> | also, you don't need to escape the spaces :-) |
| 09:06 | <zcorpan> | matjas: also see http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html |
| 09:07 | <zcorpan> | matjas: also see http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html |
| 09:07 | <matjas> | zcorpan: the difference is that the first one uses comic sans ms, but the second one doesn’t |
| 09:07 | <matjas> | zcorpan: the difference is that the first one uses comic sans ms, but the second one doesn’t |
| 09:08 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1389 |
| 09:08 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1389 |
| 09:08 | <zcorpan> | they are the same string and they both use the same font for me :-) |
| 09:09 | <zcorpan> | they are the same string and they both use the same font for me :-) |
| 09:09 | <matjas> | zcorpan: your IRC client merges multiple spaces together |
| 09:09 | <matjas> | zcorpan: your IRC client merges multiple spaces together |
| 09:09 | <zcorpan> | aha |
| 09:09 | <matjas> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1390 |
| 09:10 | <zcorpan> | aha |
| 09:10 | <matjas> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1390 |
| 09:10 | <zcorpan> | ok so you have the identifiers "\63 omic\ " and "sans\ ms" |
| 09:10 | <matjas> | the escapes spaces + the \63 was just to test identifier escapes |
| 09:10 | <zcorpan> | which after unescaping become "comic " and "sans ms" |
| 09:10 | <MikeSmith> | M7 earthquake just now off the coast of Hokkaido |
| 09:11 | <zcorpan> | ok so you have the identifiers "\63 omic\ " and "sans\ ms" |
| 09:11 | <matjas> | the escapes spaces + the \63 was just to test identifier escapes |
| 09:11 | <zcorpan> | then join with a space, you get "comic sans ms" (with two spaces between comic and sans) |
| 09:11 | <zcorpan> | which after unescaping become "comic " and "sans ms" |
| 09:11 | <MikeSmith> | M7 earthquake just now off the coast of Hokkaido |
| 09:11 | <zcorpan> | then join with a space, you get "comic sans ms" (with two spaces between comic and sans) |
| 09:11 | <zcorpan> | which doesn't match a font family name |
| 09:11 | <MikeSmith> | it is shaking things in Tokyo even |
| 09:11 | <zcorpan> | which doesn't match a font family name |
| 09:11 | <MikeSmith> | it is shaking things in Tokyo even |
| 09:11 | <matjas> | zcorpan: ok, so i shouldn’t have explicitly escaped that one space |
| 09:11 | <matjas> | got it |
| 09:11 | <MikeSmith> | I think a Tsunami is going to hit eastern Hokaido and nothern Honshu |
| 09:11 | <MikeSmith> | http://quake.twiple.jp/quake/view/20120314180905 |
| 09:12 | <matjas> | zcorpan: ok, so i shouldn’t have explicitly escaped that one space |
| 09:12 | <matjas> | got it |
| 09:12 | <MikeSmith> | I think a Tsunami is going to hit eastern Hokaido and nothern Honshu |
| 09:12 | <MikeSmith> | http://quake.twiple.jp/quake/view/20120314180905 |
| 09:14 | <MikeSmith> | http://nmz.mogken.com/20120314180905 |
| 09:15 | <MikeSmith> | http://nmz.mogken.com/20120314180905 |
| 09:17 | <zcorpan> | are there any nuclear power plants there? |
| 09:18 | <zcorpan> | are there any nuclear power plants there? |
| 09:18 | <MikeSmith> | probably |
| 09:18 | <MikeSmith> | but none running |
| 09:18 | <MikeSmith> | 52 of the 54 plants in Japan are shut down right now |
| 09:19 | <MikeSmith> | probably |
| 09:19 | <MikeSmith> | but none running |
| 09:19 | <MikeSmith> | 52 of the 54 plants in Japan are shut down right now |
| 09:19 | <MikeSmith> | anyway, news is saying the tsunami will only be .5m |
| 09:19 | <MikeSmith> | http://weather.excite.co.jp/tsunami/t-2012-03-14+18%3A12%3A56/ |
| 09:19 | <MikeSmith> | anyway, news is saying the tsunami will only be .5m |
| 09:19 | <MikeSmith> | http://weather.excite.co.jp/tsunami/t-2012-03-14+18%3A12%3A56/ |
| 09:20 | <zcorpan> | what does that mean in terms of damage? |
| 09:20 | <zcorpan> | what does that mean in terms of damage? |
| 09:20 | <MikeSmith> | probably not much I guess |
| 09:21 | <MikeSmith> | probably not much I guess |
| 09:21 | <MikeSmith> | and it's not going to his the coast for until another 20 minutes from now |
| 09:21 | <zcorpan> | "is ok to let your children play at the beach until you see the tsunami coming, at which point you should walk up the beach about 50m" or "will wipe out houses that are 150m to the beach or closer" or something in between? :-) |
| 09:22 | <MikeSmith> | and it's not going to his the coast for until another 20 minutes from now |
| 09:22 | <zcorpan> | "is ok to let your children play at the beach until you see the tsunami coming, at which point you should walk up the beach about 50m" or "will wipe out houses that are 150m to the beach or closer" or something in between? :-) |
| 09:22 | <MikeSmith> | dunno |
| 09:22 | <MikeSmith> | dunno |
| 10:06 | <hsivonen> | must. not. read. Slashdot or Ars comment threads about Mozilla & H.264. Too much 386. |
| 10:06 | <hsivonen> | must. not. read. Slashdot or Ars comment threads about Mozilla & H.264. Too much 386. |
| 10:07 | <hsivonen> | speaking people being wrong on the Internet: http://ask.slashdot.org/story/12/03/04/047248/ask-slashdot-life-after-firefox-36x?sdsrc=popbytid |
| 10:07 | zcorpan | learns that width:0 and width:0% on table cells is ignored |
| 10:07 | <hsivonen> | "3.6.x has been known for generally being more stable and using less RAM than the modern Firefox 10 and even Chrome." |
| 10:07 | <hsivonen> | speaking people being wrong on the Internet: http://ask.slashdot.org/story/12/03/04/047248/ask-slashdot-life-after-firefox-36x?sdsrc=popbytid |
| 10:07 | zcorpan | learns that width:0 and width:0% on table cells is ignored |
| 10:07 | <hsivonen> | "3.6.x has been known for generally being more stable and using less RAM than the modern Firefox 10 and even Chrome." |
| 10:09 | <zcorpan> | "Netscape 4 has been known for generally being more stable and using less RAM than the modern Internet Explorer 5.5 and even Opera." |
| 10:09 | <zcorpan> | "Netscape 4 has been known for generally being more stable and using less RAM than the modern Internet Explorer 5.5 and even Opera." |
| 10:11 | <jgraham> | People who want to talk about browser memeory consumption on the internet should be forced to either a) work for a browser vendor or b) read all of Nicolas Nethercote's blog before they get to say anything |
| 10:12 | <jgraham> | People who want to talk about browser memeory consumption on the internet should be forced to either a) work for a browser vendor or b) read all of Nicolas Nethercote's blog before they get to say anything |
| 10:12 | <jgraham> | The % of misinformation on that topic is unusually high even for the internet |
| 10:12 | <jgraham> | The % of misinformation on that topic is unusually high even for the internet |
| 10:15 | <jgraham> | (if there is anyone else providing such a useful public resource on why browsers use memory I would also happily suggest that) |
| 10:16 | <jgraham> | (if there is anyone else providing such a useful public resource on why browsers use memory I would also happily suggest that) |
| 10:16 | <Ms2ger> | jgraham, you could do something for Opera? :) |
| 10:17 | <Ms2ger> | jgraham, you could do something for Opera? :) |
| 10:17 | <jgraham> | I'm not sureI would be the right person to write that, sadly |
| 10:17 | <jgraham> | I'm not sureI would be the right person to write that, sadly |
| 10:31 | <Ms2ger> | Hixie, with those diagrams, I might finally understand what arc() does :) |
| 10:32 | <Ms2ger> | Hixie, with those diagrams, I might finally understand what arc() does :) |
| 10:36 | <zcorpan> | Ms2ger: now pretend you're on the phone and need to explain the diagrams to someone else, or the bunny gets it. what'd ya say? |
| 10:36 | <zcorpan> | Ms2ger: now pretend you're on the phone and need to explain the diagrams to someone else, or the bunny gets it. what'd ya say? |
| 10:37 | <jgraham> | Bye bye bunny? |
| 10:38 | <jgraham> | Bye bye bunny? |
| 10:40 | <zcorpan> | (bonus point for knowing the bunny reference) |
| 10:40 | <zcorpan> | (bonus point for knowing the bunny reference) |
| 10:52 | <MikeSmith> | matjas: about "criteria that cannot be expressed by a DTD, but can still be checked by a machine” see my comments in the logs |
| 10:52 | <MikeSmith> | and https://bitbucket.org/validator/syntax/src/tip/relaxng/datatype/java/src/org/whattf/datatype/ScriptDocumentation.java and https://bitbucket.org/validator/syntax/src/tip/relaxng/datatype/java/src/org/whattf/datatype/FunctionBody.java |
| 10:53 | <MikeSmith> | matjas: about "criteria that cannot be expressed by a DTD, but can still be checked by a machine” see my comments in the logs |
| 10:53 | <MikeSmith> | and https://bitbucket.org/validator/syntax/src/tip/relaxng/datatype/java/src/org/whattf/datatype/ScriptDocumentation.java and https://bitbucket.org/validator/syntax/src/tip/relaxng/datatype/java/src/org/whattf/datatype/FunctionBody.java |
| 10:53 | <MikeSmith> | those check the text content of script elements |
| 10:53 | <MikeSmith> | those check the text content of script elements |
| 10:54 | <matjas> | MikeSmith: http://krijnhoetmer.nl/irc-logs/whatwg/20120314#l-218, I missed those before, thanks! |
| 10:54 | <matjas> | MikeSmith: http://krijnhoetmer.nl/irc-logs/whatwg/20120314#l-218, I missed those before, thanks! |
| 10:54 | <MikeSmith> | cheers |
| 10:55 | <MikeSmith> | cheers |
| 11:09 | <Philip`> | jacobolus: "I thought graphics hardware was designed for multiplying square matrices!" - as I understand it, modern GPUs expand shader code into single-float instructions (e.g. "color.rgb *= 2.0" is 3 instructions, and matrix multiplications are lots) |
| 11:09 | <Philip`> | jacobolus: "I thought graphics hardware was designed for multiplying square matrices!" - as I understand it, modern GPUs expand shader code into single-float instructions (e.g. "color.rgb *= 2.0" is 3 instructions, and matrix multiplications are lots) |
| 11:09 | <Philip`> | so they're not designed for doing anything with matrices or even with vectors |
| 11:10 | <Philip`> | so they're not designed for doing anything with matrices or even with vectors |
| 11:10 | <jacobolus> | Philip`: what about when you say "here's a transformation matrix and here are points a, b, c, d in space", etc.? |
| 11:10 | <jacobolus> | Philip`: what about when you say "here's a transformation matrix and here are points a, b, c, d in space", etc.? |
| 11:11 | <Philip`> | (though they run the same shader code over ~16 streams of data in parallel, and run ~32 of those in parallel, so you get huge bandwidth even if each individual shader is many more instructions) |
| 11:11 | <Philip`> | (though they run the same shader code over ~16 streams of data in parallel, and run ~32 of those in parallel, so you get huge bandwidth even if each individual shader is many more instructions) |
| 11:12 | <Philip`> | jacobolus: That's just part of the application-facing API (or in the case of OpenGL ES it's not even there, it's entirely in the application), and gets turned into vertex shader code that multiplies the per-vertex data with the uniform transform data |
| 11:12 | <Philip`> | *ES 2.0 |
| 11:13 | <Philip`> | jacobolus: That's just part of the application-facing API (or in the case of OpenGL ES it's not even there, it's entirely in the application), and gets turned into vertex shader code that multiplies the per-vertex data with the uniform transform data |
| 11:13 | <Philip`> | *ES 2.0 |
| 11:13 | <jacobolus> | ah. I guess I should really learn openGL seriously sometime |
| 11:13 | <jacobolus> | ah. I guess I should really learn openGL seriously sometime |
| 11:15 | <Philip`> | (Old GL has e.g. VertexPointer to give it vertex positions, which originated with the fixed-function pipeline (when I guess GPUs did have dedicated hardware for vertex transforms), but GLES2 (and the non-compatibility profile of GL3.2) removes that and just has a generic semanticless vertex attribute system) |
| 11:16 | <Philip`> | (Old GL has e.g. VertexPointer to give it vertex positions, which originated with the fixed-function pipeline (when I guess GPUs did have dedicated hardware for vertex transforms), but GLES2 (and the non-compatibility profile of GL3.2) removes that and just has a generic semanticless vertex attribute system) |
| 11:16 | <Philip`> | ((and modern implementations of old GL will translate everything into the new shaderier system)) |
| 11:17 | <Philip`> | ((and modern implementations of old GL will translate everything into the new shaderier system)) |
| 11:17 | <MikeSmith> | hmm shouldn't the polyglot spec disallow CDATA sections? |
| 11:17 | <MikeSmith> | hmm shouldn't the polyglot spec disallow CDATA sections? |
| 11:17 | <jacobolus> | Philip`: can you recommend any resources for learning whatever OpenGL thing will be compatible with WebGL? |
| 11:17 | <Ms2ger> | MikeSmith, but that's the nicest part of polyglot! |
| 11:18 | <jacobolus> | Philip`: can you recommend any resources for learning whatever OpenGL thing will be compatible with WebGL? |
| 11:18 | <Ms2ger> | MikeSmith, but that's the nicest part of polyglot! |
| 11:18 | <Philip`> | jacobolus: I can't :-( |
| 11:18 | <jacobolus> | Philip`: and also, to what extent can I use WebGL just to do computation, without necessarily displaying anything on screen? |
| 11:18 | <Philip`> | jacobolus: I can't :-( |
| 11:18 | <jacobolus> | ah, darn |
| 11:18 | <jacobolus> | Philip`: and also, to what extent can I use WebGL just to do computation, without necessarily displaying anything on screen? |
| 11:18 | <jacobolus> | ah, darn |
| 11:18 | <Philip`> | (other than the obvious things like the OpenGL ES 2.0 spec and delta spec) |
| 11:19 | <Philip`> | (other than the obvious things like the OpenGL ES 2.0 spec and delta spec) |
| 11:19 | <jacobolus> | how much of that transfers to webgl? |
| 11:19 | <jacobolus> | I haven't taken much serious look at webgl |
| 11:19 | <Philip`> | I've never really learned OpenGL from anywhere specific - I've just aggregated whatever rubbish I happen to encounter on the web and assume it to be true |
| 11:19 | <jacobolus> | how much of that transfers to webgl? |
| 11:19 | <jacobolus> | I haven't taken much serious look at webgl |
| 11:19 | <Philip`> | I've never really learned OpenGL from anywhere specific - I've just aggregated whatever rubbish I happen to encounter on the web and assume it to be true |
| 11:19 | <Philip`> | so I don't know what's a good place to look |
| 11:20 | <Philip`> | so I don't know what's a good place to look |
| 11:20 | <Philip`> | (though I did recently see http://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ which seems like a nice overview of the lower-level implementation details if you already understand the basic concepts) |
| 11:21 | <Philip`> | (though I did recently see http://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ which seems like a nice overview of the lower-level implementation details if you already understand the basic concepts) |
| 11:21 | <jacobolus> | do you know if it's possible to use WebGL just for fast computation on the GPU, and not for showing anything? |
| 11:21 | <Philip`> | I've never really used WebGL, so I could be mistaken, but I believe it's very close to GLES2 |
| 11:21 | <jacobolus> | do you know if it's possible to use WebGL just for fast computation on the GPU, and not for showing anything? |
| 11:21 | <Philip`> | I've never really used WebGL, so I could be mistaken, but I believe it's very close to GLES2 |
| 11:22 | <Philip`> | You can use it to render onto an off-screen buffer, and then use that as input for further GPU processing or (very slowly) copy it back to the CPU |
| 11:22 | <Philip`> | You can use it to render onto an off-screen buffer, and then use that as input for further GPU processing or (very slowly) copy it back to the CPU |
| 11:22 | <Philip`> | but I think GLES2 (and WebGL) is pretty limited in buffer formats etc, so it's likely to be awkward to fit non-graphical problems into it |
| 11:23 | <Philip`> | but I think GLES2 (and WebGL) is pretty limited in buffer formats etc, so it's likely to be awkward to fit non-graphical problems into it |
| 11:24 | <Philip`> | (http://www.khronos.org/webcl/ is more designed for GPU computing) |
| 11:24 | <Philip`> | (http://www.khronos.org/webcl/ is more designed for GPU computing) |
| 11:25 | <zcorpan> | MikeSmith: why? |
| 11:25 | <zcorpan> | MikeSmith: why? |
| 11:25 | <Philip`> | (http://webcl.nokiaresearch.com/tutorials/tutorial4.html has an example) |
| 11:26 | <Philip`> | (http://webcl.nokiaresearch.com/tutorials/tutorial4.html has an example) |
| 11:26 | <MikeSmith> | zcorpan: because the HTML spec says it's not allowed |
| 11:26 | <MikeSmith> | zcorpan: because the HTML spec says it's not allowed |
| 11:26 | <zcorpan> | MikeSmith: it's allowed in foreign lands |
| 11:26 | <MikeSmith> | yeah I know that |
| 11:27 | <zcorpan> | MikeSmith: it's allowed in foreign lands |
| 11:27 | <MikeSmith> | yeah I know that |
| 11:27 | <MikeSmith> | but the polyglot spec should explicitly say that it's not allowed anywhere else |
| 11:27 | <MikeSmith> | but the polyglot spec should explicitly say that it's not allowed anywhere else |
| 11:27 | <zcorpan> | oh you mean like in <script>? |
| 11:28 | <zcorpan> | oh you mean like in <script>? |
| 11:28 | <jacobolus> | Philip`: well, I want to deal w/ graphical problems |
| 11:28 | <jacobolus> | Philip`: well, I want to deal w/ graphical problems |
| 11:28 | <jacobolus> | e.g. how much of this can be applied to webgl I wonder http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter24.html |
| 11:29 | <jacobolus> | e.g. how much of this can be applied to webgl I wonder http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter24.html |
| 11:30 | <zcorpan> | MikeSmith: yeah it should, although <script> and <style> might be special exceptions |
| 11:30 | <zcorpan> | MikeSmith: yeah it should, although <script> and <style> might be special exceptions |
| 11:31 | <zcorpan> | although it currently says to always use external scripts and styles, so that might not be needed then |
| 11:31 | <zcorpan> | although it currently says to always use external scripts and styles, so that might not be needed then |
| 11:31 | <Philip`> | jacobolus: GLES2 (and WebGL) doesn't support 3D textures (nor 1D textures) |
| 11:31 | <jacobolus> | ah |
| 11:31 | <jacobolus> | Philip`: can it be coaxed into doing the same kind of math? |
| 11:32 | <Philip`> | jacobolus: GLES2 (and WebGL) doesn't support 3D textures (nor 1D textures) |
| 11:32 | <jacobolus> | ah |
| 11:32 | <jacobolus> | Philip`: can it be coaxed into doing the same kind of math? |
| 11:32 | <jacobolus> | or does that require going ⇔ the CPU |
| 11:32 | <jacobolus> | or does that require going ⇔ the CPU |
| 11:32 | <zcorpan> | hmm, it's confused. "Polyglot markup includes script and style commands by linking to external files rather than including them in-line." and then "Polyglot markup uses external scripts if that document's script or style sheet uses < or & or ]]> or --." |
| 11:33 | <zcorpan> | hmm, it's confused. "Polyglot markup includes script and style commands by linking to external files rather than including them in-line." and then "Polyglot markup uses external scripts if that document's script or style sheet uses < or & or ]]> or --." |
| 11:33 | <MikeSmith> | hmm |
| 11:33 | <zcorpan> | (and the next paragraph is copied from the old xhtml 1.0 appendix c which totally misses the point) |
| 11:34 | <MikeSmith> | hmm |
| 11:34 | <zcorpan> | (and the next paragraph is copied from the old xhtml 1.0 appendix c which totally misses the point) |
| 11:35 | <Philip`> | jacobolus: I guess you might have to do it by e.g. encoding the NxNxN 3D texture as a (N*N)xN 2D texture, and writing a shader to manually sample the relevant points in the texture and to do the trilinear filtering |
| 11:36 | <Philip`> | jacobolus: I guess you might have to do it by e.g. encoding the NxNxN 3D texture as a (N*N)xN 2D texture, and writing a shader to manually sample the relevant points in the texture and to do the trilinear filtering |
| 11:36 | <jacobolus> | ah, hm |
| 11:36 | <jacobolus> | I'll have to actually read the spec sometime |
| 11:36 | <jacobolus> | ah, hm |
| 11:36 | <jacobolus> | I'll have to actually read the spec sometime |
| 11:36 | <jacobolus> | anyway, thanks for the advice, generally |
| 11:37 | <jacobolus> | anyway, thanks for the advice, generally |
| 11:37 | <Philip`> | (which I expect would be significantly slower than using the dedicated texture sampling hardware) |
| 11:37 | <Philip`> | (and maybe it'd be cheaper just to do the maths in the shader, instead of using a lookup texture) |
| 11:37 | <Philip`> | (and maybe it'd be cheaper just to do the maths in the shader, instead of using a lookup texture) |
| 11:37 | <jacobolus> | not for teh kind of math I want to do :) |
| 11:38 | <jacobolus> | not for teh kind of math I want to do :) |
| 11:40 | <jacobolus> | huh. do any implementations of apis like canvas, svg, etc. use OpenVG? |
| 11:40 | <jacobolus> | looks kind of interesting |
| 11:40 | <jacobolus> | huh. do any implementations of apis like canvas, svg, etc. use OpenVG? |
| 11:40 | <jacobolus> | looks kind of interesting |
| 11:42 | <Philip`> | I know even less about that than about anything else I've been pretending to know about, but I've never heard of anybody actually using it, so I assume it's just part of the weird mobile world |
| 11:43 | <Philip`> | I know even less about that than about anything else I've been pretending to know about, but I've never heard of anybody actually using it, so I assume it's just part of the weird mobile world |
| 11:57 | <zcorpan> | matjas: in addition to stuff that v.nu checks with java code, there's stuff that v.nu checks with relax ng that cannot be expressed in a DTD, like making checked="" invalid on <input> when type="text" |
| 11:57 | <annevk> | MikeSmith: found anything? |
| 11:57 | <MikeSmith> | no |
| 11:57 | <zcorpan> | matjas: in addition to stuff that v.nu checks with java code, there's stuff that v.nu checks with relax ng that cannot be expressed in a DTD, like making checked="" invalid on <input> when type="text" |
| 11:57 | <annevk> | MikeSmith: found anything? |
| 11:57 | <MikeSmith> | no |
| 11:58 | <MikeSmith> | matjas: yeah there is lots of stuff like what zcorpan mentions |
| 11:58 | <matjas> | zcorpan: thanks, got it. a DTD roughly lists the allowed elements/attributes and where in the document they are allowed, but that’s it |
| 11:58 | <MikeSmith> | matjas: yeah there is lots of stuff like what zcorpan mentions |
| 11:58 | <matjas> | zcorpan: thanks, got it. a DTD roughly lists the allowed elements/attributes and where in the document they are allowed, but that’s it |
| 11:58 | <MikeSmith> | DTDs have some simple dataypes too |
| 11:58 | <MikeSmith> | for constraining the values of attributes |
| 11:58 | <zcorpan> | short version is that DTDs suck and you shouldn't care about them |
| 11:58 | <MikeSmith> | yup |
| 11:58 | <matjas> | :) |
| 11:59 | <MikeSmith> | DTDs have some simple dataypes too |
| 11:59 | <MikeSmith> | for constraining the values of attributes |
| 11:59 | <zcorpan> | short version is that DTDs suck and you shouldn't care about them |
| 11:59 | <annevk> | schema languages in general |
| 11:59 | <MikeSmith> | yup |
| 11:59 | <matjas> | :) |
| 11:59 | <annevk> | schema languages in general |
| 11:59 | <zcorpan> | schema languages have limitations but don't have to suck :-) |
| 12:00 | <zcorpan> | schema languages have limitations but don't have to suck :-) |
| 12:00 | <annevk> | dunno, because they're never specific I don't think they'll ever be ideal for a particular problem |
| 12:00 | <annevk> | dunno, because they're never specific I don't think they'll ever be ideal for a particular problem |
| 12:04 | <MikeSmith> | damn |
| 12:05 | <MikeSmith> | damn |
| 12:05 | <MikeSmith> | another big earthquake |
| 12:05 | <MikeSmith> | another big earthquake |
| 12:05 | <MikeSmith> | fucking hell |
| 12:06 | <MikeSmith> | fucking hell |
| 12:06 | <MikeSmith> | I hope that one wasn't up north |
| 12:06 | <MikeSmith> | because if it was it must have been huge |
| 12:06 | <MikeSmith> | I hope that one wasn't up north |
| 12:06 | <MikeSmith> | because if it was it must have been huge |
| 12:09 | <karlcow> | http://www.jma.go.jp/en/quake/00000000089.html |
| 12:09 | <karlcow> | chiba? |
| 12:09 | <karlcow> | http://www.jma.go.jp/en/quake/00000000089.html |
| 12:09 | <karlcow> | chiba? |
| 12:09 | <annevk> | http://blog.whatwg.org/weekly-canvas-path |
| 12:09 | <MikeSmith> | karlcow: yah |
| 12:10 | <annevk> | http://blog.whatwg.org/weekly-canvas-path |
| 12:10 | <MikeSmith> | karlcow: yah |
| 12:10 | <zcorpan> | annevk: btw please regen html5-diff |
| 12:11 | <zcorpan> | annevk: btw please regen html5-diff |
| 12:11 | <annevk> | done |
| 12:12 | <annevk> | done |
| 12:12 | <annevk> | shouldn't http+aes be still mentioned for WHATWG? |
| 12:12 | <zcorpan> | it is |
| 12:12 | <annevk> | shouldn't http+aes be still mentioned for WHATWG? |
| 12:12 | <zcorpan> | it is |
| 12:12 | <annevk> | oh okay |
| 12:12 | <zcorpan> | thanks |
| 12:12 | <zcorpan> | MikeSmith: ^ |
| 12:13 | <annevk> | oh okay |
| 12:13 | <zcorpan> | thanks |
| 12:13 | <zcorpan> | MikeSmith: ^ |
| 12:29 | <scott_gonzalez> | MikeSmith: If the install is simple that'll help, but total size is probably going to be a factor as well. |
| 12:29 | <scott_gonzalez> | MikeSmith: If the install is simple that'll help, but total size is probably going to be a factor as well. |
| 12:29 | <scott_gonzalez> | If we need to triple the size of our repo just to validate HTML files, it doesn't seem worth it. |
| 12:30 | <scott_gonzalez> | If we need to triple the size of our repo just to validate HTML files, it doesn't seem worth it. |
| 12:30 | <scott_gonzalez> | I haven't actually looked at the size of everything needed for validator.nu, but it didn't sound small. |
| 12:30 | <scott_gonzalez> | I haven't actually looked at the size of everything needed for validator.nu, but it didn't sound small. |
| 12:55 | <zcorpan> | last quirk specced (while having lunch) http://simon.html5.org/specs/quirks-mode#the-table-cell-nowrap-minimum-width-calculation-quirk |
| 12:55 | <zcorpan> | last quirk specced (while having lunch) http://simon.html5.org/specs/quirks-mode#the-table-cell-nowrap-minimum-width-calculation-quirk |
| 13:11 | <annevk> | oh lunch |
| 13:11 | <annevk> | oh lunch |
| 13:13 | <annevk> | zcorpan: can the text-decoration quirk be described using http://dev.w3.org/csswg/css3-text/#text-decoration-color ? |
| 13:13 | <annevk> | zcorpan: can the text-decoration quirk be described using http://dev.w3.org/csswg/css3-text/#text-decoration-color ? |
| 13:15 | <zcorpan> | dunno |
| 13:15 | <zcorpan> | is that implemented? |
| 13:16 | <zcorpan> | dunno |
| 13:16 | <zcorpan> | is that implemented? |
| 13:16 | <annevk> | prefixed in Gecko purportedly |
| 13:17 | <annevk> | prefixed in Gecko purportedly |
| 13:17 | <zcorpan> | seems that property doesn't do what the quirk does |
| 13:17 | <zcorpan> | seems that property doesn't do what the quirk does |
| 13:53 | <annevk> | zcorpan: gonna tweet about being done? |
| 13:53 | <annevk> | zcorpan: gonna tweet about being done? |
| 13:53 | <zcorpan> | i'm far from done :-) |
| 13:53 | <annevk> | 80% done |
| 13:54 | <zcorpan> | i'm far from done :-) |
| 13:54 | <annevk> | 80% done |
| 13:54 | <zcorpan> | tweeted |
| 13:55 | <zcorpan> | tweeted |
| 13:55 | <annevk> | ta |
| 13:55 | <annevk> | ta |
| 14:27 | <StoneCypher> | is there a field intended for universal per-language text replacement (i18n string tables) |
| 14:27 | <StoneCypher> | is there a field intended for universal per-language text replacement (i18n string tables) |
| 14:27 | <StoneCypher> | or should i be making a data-foo attribute |
| 14:27 | <StoneCypher> | or should i be making a data-foo attribute |
| 14:33 | <zcorpan> | i guess now is a good time to get quirks mode in a VCS |
| 14:34 | <zcorpan> | i guess now is a good time to get quirks mode in a VCS |
| 14:36 | <zcorpan> | MikeSmith: did you update the TR? |
| 14:37 | <zcorpan> | MikeSmith: did you update the TR? |
| 14:37 | <MikeSmith> | not yet |
| 14:37 | <MikeSmith> | not yet |
| 14:37 | <zcorpan> | k, just checking |
| 14:37 | <zcorpan> | i'm not in a hurry :-) |
| 14:37 | <zcorpan> | k, just checking |
| 14:37 | <zcorpan> | i'm not in a hurry :-) |
| 14:37 | zcorpan | -> offline |
| 14:38 | zcorpan | -> offline |
| 15:20 | <hsivonen> | what MIME type does IE9 want to see for AAC audio files? |
| 15:20 | <hsivonen> | what MIME type does IE9 want to see for AAC audio files? |
| 15:20 | <hsivonen> | audio/mp4? |
| 15:21 | <hsivonen> | audio/mp4? |
| 15:36 | <Ms2ger> | "XForms Users Community Group" |
| 15:37 | <Ms2ger> | "XForms Users Community Group" |
| 15:37 | <hober> | shouldn't that be "User's" :) |
| 15:37 | <hober> | oh, that guy |
| 15:37 | <hober> | shouldn't that be "User's" :) |
| 15:37 | <hober> | oh, that guy |
| 15:38 | <jgraham> | aka the "John Boyer Community Group" |
| 15:38 | <Ms2ger> | "John Boyer, Trucker, Killed 3 Prostitutes Across South" |
| 15:38 | <jgraham> | aka the "John Boyer Community Group" |
| 15:38 | <Ms2ger> | "John Boyer, Trucker, Killed 3 Prostitutes Across South" |
| 15:38 | Ms2ger | assumes another John Boyer |
| 15:39 | Ms2ger | assumes another John Boyer |
| 15:40 | <jgraham> | Yeah, this is John M. Boyer, the Sci-Fi one |
| 15:40 | <jgraham> | https://www.ibm.com/developerworks/mydeveloperworks/blogs/JohnBoyer/?lang=en |
| 15:40 | <jgraham> | Yeah, this is John M. Boyer, the Sci-Fi one |
| 15:40 | <jgraham> | https://www.ibm.com/developerworks/mydeveloperworks/blogs/JohnBoyer/?lang=en |
| 15:42 | <annevk> | did not take long: http://www.w3.org/community/xformsusers/ |
| 15:42 | <Ms2ger> | "It is really easy to use XPath..." |
| 15:42 | Ms2ger | stops reading |
| 15:43 | <annevk> | did not take long: http://www.w3.org/community/xformsusers/ |
| 15:43 | <Ms2ger> | "It is really easy to use XPath..." |
| 15:43 | Ms2ger | stops reading |
| 15:45 | <Philip`> | "View all 1 Participants" - someone else needs to join the group to save the world from terrible grammar |
| 15:46 | <Philip`> | "View all 1 Participants" - someone else needs to join the group to save the world from terrible grammar |
| 15:47 | <jgraham> | Because "View all 2 Participants" will just sound like irony? |
| 15:48 | <jgraham> | Because "View all 2 Participants" will just sound like irony? |
| 15:48 | <smaug____> | Ms2ger: XPath isn't bad |
| 15:49 | <smaug____> | Ms2ger: XPath isn't bad |
| 15:49 | <Ms2ger> | It's better than XForms, I guess :) |
| 15:49 | <smaug____> | yes :) |
| 15:49 | <Ms2ger> | It's better than XForms, I guess :) |
| 15:49 | <smaug____> | yes :) |
| 15:56 | <kennyluck> | "View both Participants" is better maybe? :p |
| 15:56 | <kennyluck> | "View both Participants" is better maybe? :p |
| 16:15 | <smaug____> | annevk: where does DOM4 say when node is removed from the old parent when inserting to be a child of a new parent |
| 16:15 | <Ms2ger> | Btw, MikeSmith, weird Glenn wanted a bugzilla component for http://dvcs.w3.org/hg/csswg/raw-file/tip/cssom-values/Overview.html |
| 16:15 | <smaug____> | annevk: where does DOM4 say when node is removed from the old parent when inserting to be a child of a new parent |
| 16:15 | <Ms2ger> | Btw, MikeSmith, weird Glenn wanted a bugzilla component for http://dvcs.w3.org/hg/csswg/raw-file/tip/cssom-values/Overview.html |
| 16:15 | <Ms2ger> | smaug____, it might not say that :) |
| 16:15 | <MikeSmith> | Ms2ger: thanks |
| 16:16 | <Ms2ger> | smaug____, it might not say that :) |
| 16:16 | <MikeSmith> | Ms2ger: thanks |
| 16:16 | <annevk> | smaug____: as part of adopting it? |
| 16:16 | <annevk> | smaug____: as part of adopting it? |
| 16:16 | <smaug____> | huh |
| 16:16 | <Ms2ger> | No, just removing it from childNodes |
| 16:17 | <smaug____> | huh |
| 16:17 | <Ms2ger> | Ah, yes |
| 16:17 | <Ms2ger> | No, just removing it from childNodes |
| 16:17 | <Ms2ger> | Ah, yes |
| 16:17 | <smaug____> | but ok |
| 16:17 | <Ms2ger> | That's weird, but sure |
| 16:17 | <smaug____> | but ok |
| 16:17 | <Ms2ger> | That's weird, but sure |
| 16:17 | <annevk> | how is it weird? |
| 16:17 | <annevk> | pre-insert step 6 |
| 16:18 | <annevk> | how is it weird? |
| 16:18 | <annevk> | pre-insert step 6 |
| 16:18 | <smaug____> | just hard to read |
| 16:18 | <Ms2ger> | I'd have expected the adopt algorithm to be a no-op if the node already had the right node document |
| 16:19 | <smaug____> | just hard to read |
| 16:19 | <Ms2ger> | I'd have expected the adopt algorithm to be a no-op if the node already had the right node document |
| 16:19 | <smaug____> | looks like nodes aren't ever removed from documentfragment |
| 16:19 | <smaug____> | looks like nodes aren't ever removed from documentfragment |
| 16:19 | <smaug____> | when inserting a documentfragment |
| 16:19 | <annevk> | ah yeah, DocumentFragment has issues :( |
| 16:19 | <annevk> | patches appreciated |
| 16:20 | <smaug____> | when inserting a documentfragment |
| 16:20 | <annevk> | ah yeah, DocumentFragment has issues :( |
| 16:20 | <annevk> | patches appreciated |
| 16:21 | <smaug____> | and replace's mutation observer handling is probably wrong |
| 16:21 | <smaug____> | and replace's mutation observer handling is probably wrong |
| 16:21 | <annevk> | is that even specced yet? |
| 16:22 | <annevk> | is that even specced yet? |
| 16:22 | <smaug____> | replace removes and inserts |
| 16:22 | <smaug____> | so it will create two mutationrecords |
| 16:22 | <smaug____> | replace removes and inserts |
| 16:22 | <smaug____> | so it will create two mutationrecords |
| 16:22 | <annevk> | yeah that's wrong |
| 16:22 | <annevk> | replace all is even more wrong |
| 16:23 | <annevk> | yeah that's wrong |
| 16:23 | <annevk> | replace all is even more wrong |
| 16:23 | <annevk> | I guess I should look into fixing that, but it requires a lot of staring and a clear head |
| 16:24 | <annevk> | I guess I should look into fixing that, but it requires a lot of staring and a clear head |
| 16:32 | <smaug____> | annevk: I'll file some bug |
| 16:32 | <smaug____> | s |
| 16:33 | <smaug____> | annevk: I'll file some bug |
| 16:33 | <smaug____> | s |
| 16:35 | <annevk> | write some patches pretty please :) |
| 16:36 | <annevk> | write some patches pretty please :) |
| 16:36 | <annevk> | also, please go through https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM&resolution=--- first |
| 16:36 | <annevk> | e.g. DocumentFragment is known |
| 16:36 | <annevk> | also, please go through https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM&resolution=--- first |
| 16:36 | <annevk> | e.g. DocumentFragment is known |
| 16:37 | <Ms2ger> | MikeSmith, oh, and we should probably have a bugzilla component for random stuff, like https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 |
| 16:38 | <Ms2ger> | MikeSmith, oh, and we should probably have a bugzilla component for random stuff, like https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 |
| 16:42 | <dglazkov> | good morning, Whatwg! |
| 16:42 | <annevk> | morning hat |
| 16:42 | <annevk> | euh dglazkov |
| 16:42 | <dglazkov> | good morning, Whatwg! |
| 16:42 | <annevk> | morning hat |
| 16:42 | <annevk> | euh dglazkov |
| 16:42 | <dglazkov> | :) |
| 16:43 | <dglazkov> | :) |
| 17:00 | <aklein> | Hixie: regarding form controls outside the document, it seems that this causes problems with the definition of the "elements" collection: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15704 |
| 17:01 | <aklein> | Hixie: regarding form controls outside the document, it seems that this causes problems with the definition of the "elements" collection: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15704 |
| 17:01 | <Hixie> | hm yeah |
| 17:02 | <Hixie> | hm yeah |
| 18:19 | StoneCypher | tries again |
| 18:19 | <StoneCypher> | is there a field intended for universal per-language text replacement (i18n string tables), or should i be making a data-foo attribute |
| 18:19 | StoneCypher | tries again |
| 18:19 | <StoneCypher> | is there a field intended for universal per-language text replacement (i18n string tables), or should i be making a data-foo attribute |
| 18:22 | <Philip`> | I think the spec expects that you will do the text replacement on the server, and then you can use whatever custom design you want since it doesn't need to be conforming HTML |
| 18:22 | <Philip`> | I think the spec expects that you will do the text replacement on the server, and then you can use whatever custom design you want since it doesn't need to be conforming HTML |
| 18:22 | <Philip`> | so it doesn't provide any specific support for that |
| 18:23 | <Philip`> | so it doesn't provide any specific support for that |
| 18:27 | <StoneCypher> | kay. |
| 18:27 | <StoneCypher> | kay. |
| 18:27 | <StoneCypher> | would you think data-i18n a logical field name? |
| 18:28 | <StoneCypher> | would you think data-i18n a logical field name? |
| 18:30 | <Philip`> | Sounds a bit non-specific - something like data-i18n-stringid (or whatever the field is meant to actually be) might be less confusing, particularly if you add other i18n-related fields later |
| 18:31 | <Philip`> | Sounds a bit non-specific - something like data-i18n-stringid (or whatever the field is meant to actually be) might be less confusing, particularly if you add other i18n-related fields later |
| 18:31 | <StoneCypher> | good point |
| 18:31 | <StoneCypher> | the industry nominal would be data-i18n-key |
| 18:31 | <StoneCypher> | i think i'll use that, other points notwithstanding |
| 18:31 | <StoneCypher> | good point |
| 18:31 | <StoneCypher> | the industry nominal would be data-i18n-key |
| 18:31 | <StoneCypher> | i think i'll use that, other points notwithstanding |
| 18:59 | <scott_gonzalez> | StoneCypher: How do you plan on using that? |
| 19:00 | <scott_gonzalez> | StoneCypher: How do you plan on using that? |
| 19:10 | <kennyluck> | I love you and my wife! |
| 19:11 | <kennyluck> | I love you and my wife! |
| 19:11 | <Ms2ger> | Love you too, kennyluck |
| 19:11 | <Ms2ger> | Love you too, kennyluck |
| 19:11 | <kennyluck> | lol |
| 19:12 | <kennyluck> | lol |
| 19:23 | <othermaciej_> | Hixie: looks like https://www.w3.org/Bugs/Public/show_bug.cgi?id=11124 is resolved now? (from skimming the w3c copy of the spec) |
| 19:23 | <othermaciej_> | Hixie: time to close the bug? |
| 19:24 | <othermaciej_> | Hixie: looks like https://www.w3.org/Bugs/Public/show_bug.cgi?id=11124 is resolved now? (from skimming the w3c copy of the spec) |
| 19:24 | <othermaciej_> | Hixie: time to close the bug? |
| 19:44 | <StoneCypher> | scott_gonzalez: text content overwriting by key name |
| 19:44 | <StoneCypher> | scott_gonzalez: text content overwriting by key name |
| 19:44 | <StoneCypher> | scott_gonzalez: roughly what moustache does, without all the functional silliness |
| 19:44 | <scott_gonzalez> | But you're not using templates for it? |
| 19:45 | <StoneCypher> | scott_gonzalez: roughly what moustache does, without all the functional silliness |
| 19:45 | <scott_gonzalez> | But you're not using templates for it? |
| 19:45 | <StoneCypher> | they aren't needed for what i'm up to |
| 19:45 | <StoneCypher> | they aren't needed for what i'm up to |
| 19:45 | <StoneCypher> | if someone wants templates, more power to them |
| 19:45 | <scott_gonzalez> | You're doing dynamic translations of specific elements? |
| 19:45 | <StoneCypher> | it's just string table substitution. |
| 19:46 | <StoneCypher> | if someone wants templates, more power to them |
| 19:46 | <scott_gonzalez> | You're doing dynamic translations of specific elements? |
| 19:46 | <StoneCypher> | it's just string table substitution. |
| 19:46 | <scott_gonzalez> | But it's after page load? |
| 19:46 | <StoneCypher> | yes |
| 19:46 | <scott_gonzalez> | But it's after page load? |
| 19:46 | <StoneCypher> | yes |
| 19:46 | <scott_gonzalez> | And you're storing the lookup key in the data attribute, right? Not a specific translation. |
| 19:47 | <scott_gonzalez> | And you're storing the lookup key in the data attribute, right? Not a specific translation. |
| 19:47 | <StoneCypher> | correct |
| 19:47 | <StoneCypher> | correct |
| 20:00 | <hober> | Hixie: in http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#phrasing-content shouldn't <object> be like <a>, <ins>, and others? i.e. shouldn't it have a "(if it contains only phrasing content)" parenthetical? |
| 20:01 | <hober> | Hixie: in http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#phrasing-content shouldn't <object> be like <a>, <ins>, and others? i.e. shouldn't it have a "(if it contains only phrasing content)" parenthetical? |
| 20:29 | <annevk> | hober: yes |
| 20:29 | <annevk> | hober: you should file a bug I guess |
| 20:30 | <annevk> | hober: yes |
| 20:30 | <annevk> | hober: you should file a bug I guess |
| 20:32 | <Ms2ger> | http://lists.w3.org/Archives/Public/spec-prod/2012JanMar/0023.html \o/ |
| 20:32 | <Hixie> | hober: possibly, can't look right now |
| 20:32 | <Hixie> | othermaciej: if that's the julian thing, sure |
| 20:33 | <Ms2ger> | http://lists.w3.org/Archives/Public/spec-prod/2012JanMar/0023.html \o/ |
| 20:33 | <Hixie> | hober: possibly, can't look right now |
| 20:33 | <Hixie> | othermaciej: if that's the julian thing, sure |
| 20:38 | AryehGregor | cannot seem to get scroll() to work right in his reftest viewer thing -- something to do with calling it inside an iframe? |
| 20:39 | AryehGregor | cannot seem to get scroll() to work right in his reftest viewer thing -- something to do with calling it inside an iframe? |
| 20:43 | AryehGregor | wonders how the CSS 2.1 test suite tests scrolling |
| 20:43 | <AryehGregor> | (manually?) |
| 20:43 | <Ms2ger> | It does? |
| 20:44 | AryehGregor | wonders how the CSS 2.1 test suite tests scrolling |
| 20:44 | <AryehGregor> | (manually?) |
| 20:44 | <Ms2ger> | It does? |
| 20:44 | <AryehGregor> | Or maybe it just doesn't? |
| 20:44 | <AryehGregor> | Or maybe it just doesn't? |
| 20:44 | <annevk> | prolly doesn't |
| 20:44 | <annevk> | I know Hixie has a few manual tests related to scrolling |
| 20:44 | <Ms2ger> | It tests that padding-left: 3.2ex works |
| 20:44 | <annevk> | prolly doesn't |
| 20:44 | <annevk> | I know Hixie has a few manual tests related to scrolling |
| 20:44 | <Ms2ger> | It tests that padding-left: 3.2ex works |
| 20:44 | <AryehGregor> | http://test.csswg.org/suites/css2.1/20110323/html4/background-attachment-005.htm |
| 20:44 | <Ms2ger> | But little more involved |
| 20:45 | <AryehGregor> | http://test.csswg.org/suites/css2.1/20110323/html4/background-attachment-005.htm |
| 20:45 | <Ms2ger> | But little more involved |
| 20:45 | <annevk> | AryehGregor: invoking scroll() should work... are you invoking it on the right window? :) |
| 20:45 | <annevk> | AryehGregor: invoking scroll() should work... are you invoking it on the right window? :) |
| 20:45 | <AryehGregor> | annevk, I'm doing scroll() in a <script>. But when I do it from an iframe viewer thing, it doesn't work in all browsers. |
| 20:46 | <AryehGregor> | annevk, I'm doing scroll() in a <script>. But when I do it from an iframe viewer thing, it doesn't work in all browsers. |
| 20:46 | <gsnedders> | AryehGregor: Manually. |
| 20:46 | <gsnedders> | AryehGregor: It tests everything manually, pretty much :P |
| 20:46 | <Ms2ger> | Heh: http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwww.w3.org%2FStyleSheets%2FTR%2FW3C-ED&profile=css21&usermedium=all&warning=1&vextwarning=&lang=en#warnings |
| 20:46 | <AryehGregor> | annevk, look at this: http://aryeh.name/tmp/css-test/contributors/aryehgregor/incoming/ref-2d/fixed-background-1b.html |
| 20:46 | <gsnedders> | AryehGregor: Manually. |
| 20:46 | <gsnedders> | AryehGregor: It tests everything manually, pretty much :P |
| 20:46 | <Ms2ger> | Heh: http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwww.w3.org%2FStyleSheets%2FTR%2FW3C-ED&profile=css21&usermedium=all&warning=1&vextwarning=&lang=en#warnings |
| 20:46 | <AryehGregor> | annevk, look at this: http://aryeh.name/tmp/css-test/contributors/aryehgregor/incoming/ref-2d/fixed-background-1b.html |
| 20:46 | <AryehGregor> | And then at this: http://aryeh.name/tmp/css-test/contributors/aryehgregor/incoming/viewer.html |
| 20:46 | <AryehGregor> | But quickly, before I change them. :) |
| 20:46 | <AryehGregor> | The second just loads the first in an iframe. |
| 20:46 | <AryehGregor> | But in the iframe, scroll() doesn't work. |
| 20:47 | <AryehGregor> | And then at this: http://aryeh.name/tmp/css-test/contributors/aryehgregor/incoming/viewer.html |
| 20:47 | <AryehGregor> | But quickly, before I change them. :) |
| 20:47 | <AryehGregor> | The second just loads the first in an iframe. |
| 20:47 | <AryehGregor> | In some browsers. |
| 20:47 | <AryehGregor> | But in the iframe, scroll() doesn't work. |
| 20:47 | <AryehGregor> | In some browsers. |
| 20:47 | <AryehGregor> | It does in Chrome. |
| 20:47 | <AryehGregor> | But not IE or Firefox. |
| 20:47 | <AryehGregor> | It does in Chrome. |
| 20:47 | <AryehGregor> | But not IE or Firefox. |
| 20:47 | <AryehGregor> | Also works in Opera. |
| 20:48 | <AryehGregor> | Also works in Opera. |
| 20:48 | <annevk> | is it supposed to go up and down? |
| 20:48 | <annevk> | works in my Firefox |
| 20:48 | <AryehGregor> | It's flipping back and forth between two things. |
| 20:48 | <AryehGregor> | Just a sec. |
| 20:48 | <annevk> | works in my Firefox |
| 20:48 | <AryehGregor> | It's flipping back and forth between two things. |
| 20:48 | <AryehGregor> | Just a sec. |
| 20:48 | <annevk> | also works in IE |
| 20:48 | <AryehGregor> | Try now. |
| 20:49 | <annevk> | also works in IE |
| 20:49 | <AryehGregor> | Try now. |
| 20:49 | <AryehGregor> | The iframe is scrolled in viewer.html? |
| 20:49 | <AryehGregor> | What versions are you using? |
| 20:49 | <AryehGregor> | The iframe is scrolled in viewer.html? |
| 20:49 | <AryehGregor> | What versions are you using? |
| 20:49 | <AryehGregor> | In Firefox I see no scrollbars at all in the iframe. In IE I see scrollbars, but it's not scrolled. |
| 20:50 | <AryehGregor> | In Firefox I see no scrollbars at all in the iframe. In IE I see scrollbars, but it's not scrolled. |
| 20:51 | <annevk> | hmm now it's not |
| 20:51 | <annevk> | hmm now it's not |
| 20:51 | <annevk> | weird |
| 20:52 | <annevk> | weird |
| 20:52 | <AryehGregor> | Oh, wait. |
| 20:52 | <AryehGregor> | Oh, wait. |
| 20:52 | <AryehGregor> | When the iframe is first loaded, it's display: none, I think. |
| 20:52 | <AryehGregor> | Maybe that's it? |
| 20:52 | AryehGregor | tests |
| 20:52 | <AryehGregor> | That seems to be it. |
| 20:53 | <AryehGregor> | When the iframe is first loaded, it's display: none, I think. |
| 20:53 | <AryehGregor> | Maybe that's it? |
| 20:53 | AryehGregor | tests |
| 20:53 | <AryehGregor> | That seems to be it. |
| 20:53 | <AryehGregor> | <!DOCTYPE html> |
| 20:53 | <AryehGregor> | <iframe style=display:none src=http://aryeh.name/tmp/css-test/contributors/aryehgregor/incoming/ref-2d/fixed-background-1b.html onload="this.style.display='block'"></iframe> |
| 20:53 | <AryehGregor> | Seems like a bug in Firefox/IE. |
| 20:53 | <TabAtkins_> | Sigh. I love how a11y people always write completely unreadable emails, using color and indentation (which doesn't carry over well when crossing formats) to indicate different speakers or quotations. |
| 20:53 | <AryehGregor> | <!DOCTYPE html> |
| 20:53 | <AryehGregor> | <iframe style=display:none src=http://aryeh.name/tmp/css-test/contributors/aryehgregor/incoming/ref-2d/fixed-background-1b.html onload="this.style.display='block'"></iframe> |
| 20:53 | <AryehGregor> | Seems like a bug in Firefox/IE. |
| 20:53 | <TabAtkins_> | Sigh. I love how a11y people always write completely unreadable emails, using color and indentation (which doesn't carry over well when crossing formats) to indicate different speakers or quotations. |
| 20:54 | <AryehGregor> | In a display: none iframe, is the viewport defined? |
| 20:54 | <AryehGregor> | In a display: none iframe, is the viewport defined? |
| 20:54 | <AryehGregor> | CSS 2.1 (of course) doesn't say that I see. |
| 20:54 | <TabAtkins_> | Iframes are out-of-scope. |
| 20:54 | <AryehGregor> | They're not out-of-scope of the web platform. *Something* should say. |
| 20:55 | <AryehGregor> | CSS 2.1 (of course) doesn't say that I see. |
| 20:55 | <TabAtkins_> | Iframes are out-of-scope. |
| 20:55 | <AryehGregor> | They're not out-of-scope of the web platform. *Something* should say. |
| 20:55 | <TabAtkins_> | But since no box is created in the inner document, I doubt there's a viewport. |
| 20:55 | <AryehGregor> | So what do all the CSSOM methods do that talk about viewports? |
| 20:55 | <AryehGregor> | So what do all the CSSOM methods do that talk about viewports? |
| 20:55 | <TabAtkins_> | I dunno. |
| 20:55 | <TabAtkins_> | Presumably undefined things. |
| 20:55 | <TabAtkins_> | Likely involving 0. |
| 20:55 | <TabAtkins_> | The CSSOM sucks. File bugs? |
| 20:56 | <TabAtkins_> | I dunno. |
| 20:56 | <TabAtkins_> | Presumably undefined things. |
| 20:56 | <TabAtkins_> | Likely involving 0. |
| 20:56 | <TabAtkins_> | The CSSOM sucks. File bugs? |
| 20:56 | <AryehGregor> | Sigh. |
| 20:56 | <AryehGregor> | Sigh. |
| 20:56 | <TabAtkins_> | This shit hasn't been touched in *years*. |
| 20:56 | <Ms2ger> | We've got 3 CSSOMs now, even |
| 20:56 | AryehGregor | works around it for now by not setting display: none until after load |
| 20:57 | <TabAtkins_> | This shit hasn't been touched in *years*. |
| 20:57 | <Ms2ger> | We've got 3 CSSOMs now, even |
| 20:57 | AryehGregor | works around it for now by not setting display: none until after load |
| 20:58 | <annevk> | AryehGregor: never really considered display:none iframes :/ |
| 20:58 | <annevk> | AryehGregor: never really considered display:none iframes :/ |
| 20:58 | <annevk> | AryehGregor: it makes some sense to me that scrolling would not work there |
| 20:58 | <AryehGregor> | It's probably more convenient for authors if it does, and more convenient for implementers if it doesn't. |
| 20:59 | <annevk> | AryehGregor: it makes some sense to me that scrolling would not work there |
| 20:59 | <AryehGregor> | It's probably more convenient for authors if it does, and more convenient for implementers if it doesn't. |
| 20:59 | <StoneCypher> | should contenteditable=false inside a contenteditable=true region work? |
| 20:59 | StoneCypher | can't decide if he's doing something braindead or if the browsers aren't behaving as one would like |
| 21:00 | <StoneCypher> | should contenteditable=false inside a contenteditable=true region work? |
| 21:00 | StoneCypher | can't decide if he's doing something braindead or if the browsers aren't behaving as one would like |
| 21:00 | <AryehGregor> | StoneCypher, yes. Browsers are known to have major bugs in this area, though. |
| 21:00 | <AryehGregor> | Also, exactly what it should do is somewhat questionable. |
| 21:00 | <AryehGregor> | My spec says one thing, browsers do all sorts of things. |
| 21:00 | <AryehGregor> | StoneCypher, yes. Browsers are known to have major bugs in this area, though. |
| 21:00 | <AryehGregor> | Also, exactly what it should do is somewhat questionable. |
| 21:00 | <AryehGregor> | My spec says one thing, browsers do all sorts of things. |
| 21:00 | <annevk> | AryehGregor: it would be consistent with display:none on overflow:scroll frames if it didn't |
| 21:00 | <StoneCypher> | is there a less hackish way to get small non-editable but removable pieces of text in a contenteditable region than to put little canvasses in and draw text on them? (amusingly, <svg><text>foo</text></svg> remains editable in firefox) |
| 21:01 | <annevk> | AryehGregor: it would be consistent with display:none on overflow:scroll frames if it didn't |
| 21:01 | <StoneCypher> | is there a less hackish way to get small non-editable but removable pieces of text in a contenteditable region than to put little canvasses in and draw text on them? (amusingly, <svg><text>foo</text></svg> remains editable in firefox) |
| 21:01 | <Ms2ger> | contenteditable=no? |
| 21:01 | <Ms2ger> | contenteditable=no? |
| 21:01 | <StoneCypher> | does what one wants in two of the seven places. |
| 21:01 | <StoneCypher> | major* |
| 21:02 | <StoneCypher> | does what one wants in two of the seven places. |
| 21:02 | <StoneCypher> | major* |
| 21:02 | <AryehGregor> | Ms2ger, false, not no. |
| 21:02 | <Ms2ger> | Sure |
| 21:03 | <AryehGregor> | Ms2ger, false, not no. |
| 21:03 | <Ms2ger> | Sure |
| 21:03 | <AryehGregor> | StoneCypher, in theory, <span contenteditable=false> should do that. In practice, yeah, hacks. |
| 21:03 | <AryehGregor> | StoneCypher, in theory, <span contenteditable=false> should do that. In practice, yeah, hacks. |
| 21:03 | <StoneCypher> | yeah :( |
| 21:03 | <StoneCypher> | well, At Least It's Possible-Ish (tm) |
| 21:03 | <StoneCypher> | yeah :( |
| 21:03 | <StoneCypher> | well, At Least It's Possible-Ish (tm) |
| 21:03 | <StoneCypher> | getting text height right is going to be a blast |
| 21:04 | <StoneCypher> | getting text height right is going to be a blast |
| 21:04 | <AryehGregor> | TabAtkins_, annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16380 |
| 21:04 | <AryehGregor> | TabAtkins_, annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16380 |
| 21:05 | <TabAtkins_> | I had no idea scroll() was a function. |
| 21:06 | <TabAtkins_> | I had no idea scroll() was a function. |
| 21:06 | <zewt> | scrollTo has one of the worst abominations ever on android's browser: unlike the rest of the web universe, it smooth scrolls |
| 21:06 | <AryehGregor> | Then you learned something new today! |
| 21:06 | <zewt> | scrollTo has one of the worst abominations ever on android's browser: unlike the rest of the web universe, it smooth scrolls |
| 21:06 | <AryehGregor> | Then you learned something new today! |
| 21:06 | <zewt> | caused me no end of migraines |
| 21:06 | <annevk> | CSS should probably define the basics here though |
| 21:06 | <Ms2ger> | He. He. He. |
| 21:06 | <annevk> | because this affects getComputedStyle etc. too |
| 21:07 | <zewt> | caused me no end of migraines |
| 21:07 | <annevk> | CSS should probably define the basics here though |
| 21:07 | <Ms2ger> | He. He. He. |
| 21:07 | <annevk> | because this affects getComputedStyle etc. too |
| 21:07 | <TabAtkins_> | Yes. Even if it's something like "no document exists yet", it needs defined behavior. |
| 21:07 | <TabAtkins_> | Yes. Even if it's something like "no document exists yet", it needs defined behavior. |
| 21:07 | <TabAtkins_> | Though I suspect if we just define it as equivalent to display:none on the root, the rest would fall out. |
| 21:08 | <TabAtkins_> | Though I suspect if we just define it as equivalent to display:none on the root, the rest would fall out. |
| 21:08 | <TabAtkins_> | We already know what getComputedStyle does when querying an element that didn't generate a box. |
| 21:08 | <annevk> | display:none on root computed to block I think |
| 21:08 | <TabAtkins_> | We already know what getComputedStyle does when querying an element that didn't generate a box. |
| 21:08 | <annevk> | display:none on root computed to block I think |
| 21:08 | <annevk> | oh maybe it doesn't |
| 21:08 | <TabAtkins_> | dunno |
| 21:08 | <annevk> | data:text/html,<style>:root{display:none}</style>x |
| 21:08 | <annevk> | suggests it doesn't |
| 21:08 | <annevk> | but who knows |
| 21:09 | <annevk> | oh maybe it doesn't |
| 21:09 | <TabAtkins_> | dunno |
| 21:09 | <annevk> | data:text/html,<style>:root{display:none}</style>x |
| 21:09 | <annevk> | suggests it doesn't |
| 21:09 | <annevk> | but who knows |
| 21:09 | <annevk> | per http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo it ought to work |
| 21:10 | <annevk> | per http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo it ought to work |
| 21:10 | <annevk> | but if you don't display the root you still have a viewport... |
| 21:10 | <annevk> | but if you don't display the root you still have a viewport... |
| 21:10 | <TabAtkins_> | True. |
| 21:10 | <annevk> | I wonder if it's defined in CSS 2.1 if you have a background on root and display:none |
| 21:10 | <TabAtkins_> | But it has zero height, and default width. |
| 21:10 | <annevk> | I guess technically that should draw the background |
| 21:10 | <annevk> | because it's not the background of the root, but of the initial containing block |
| 21:11 | <TabAtkins_> | True. |
| 21:11 | <annevk> | I wonder if it's defined in CSS 2.1 if you have a background on root and display:none |
| 21:11 | <TabAtkins_> | But it has zero height, and default width. |
| 21:11 | <annevk> | I guess technically that should draw the background |
| 21:11 | <annevk> | because it's not the background of the root, but of the initial containing block |
| 21:11 | <annevk> | lets test :) |
| 21:11 | <annevk> | lets test :) |
| 21:11 | <TabAtkins_> | Chrome doesn't draw. |
| 21:11 | <TabAtkins_> | But I think you're right, technically. |
| 21:11 | <TabAtkins_> | We lift the bg to the canvas. |
| 21:12 | <TabAtkins_> | Chrome doesn't draw. |
| 21:12 | <TabAtkins_> | But I think you're right, technically. |
| 21:12 | <TabAtkins_> | We lift the bg to the canvas. |
| 21:12 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cstyle%3E%3Aroot%7Bbackground%3Aurl(image)%3Bdisplay%3Anone%7D%3C%2Fstyle%3ETEST |
| 21:12 | <annevk> | Opera draws |
| 21:12 | <annevk> | victory |
| 21:12 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cstyle%3E%3Aroot%7Bbackground%3Aurl(image)%3Bdisplay%3Anone%7D%3C%2Fstyle%3ETEST |
| 21:12 | <annevk> | Opera draws |
| 21:12 | <annevk> | victory |
| 21:13 | <annevk> | IE has a weird rendering issue, but seems to get the right idea |
| 21:13 | <annevk> | IE has a weird rendering issue, but seems to get the right idea |
| 21:13 | <annevk> | that is by far the most useless piece of CSS trickery I've done |
| 21:13 | <annevk> | apart from maybe playing around with form controls as root elements |
| 21:14 | <annevk> | that is by far the most useless piece of CSS trickery I've done |
| 21:14 | <annevk> | apart from maybe playing around with form controls as root elements |
| 21:14 | <annevk> | but it does show that you actually need to define what happens to the initial containing block as well :) |
| 21:14 | <annevk> | but it does show that you actually need to define what happens to the initial containing block as well :) |
| 21:48 | <othermaciej> | Hixie: it is |
| 21:48 | <othermaciej> | Hixie: it is |
| 21:53 | <annevk> | othermaciej: when was that changed then? |
| 21:53 | <annevk> | othermaciej: ooh, is Mike applying it himself? |
| 21:54 | <annevk> | othermaciej: when was that changed then? |
| 21:54 | <annevk> | othermaciej: ooh, is Mike applying it himself? |
| 21:54 | <othermaciej> | annevk: Mike made a script which Ian put in his publication pipeline |
| 21:55 | <othermaciej> | annevk: Mike made a script which Ian put in his publication pipeline |
| 21:55 | <Hixie> | in other news, i no longer vouch for the accuracy of anything in the w3c html spec |
| 21:55 | <Hixie> | in other news, i no longer vouch for the accuracy of anything in the w3c html spec |
| 21:55 | <Hixie> | as i strongly suspect that this has introduced all kinds of subtle bugs, e.g. in the parser |
| 21:55 | <jamesr_> | you did before? |
| 21:56 | <Hixie> | as i strongly suspect that this has introduced all kinds of subtle bugs, e.g. in the parser |
| 21:56 | <jamesr_> | you did before? |
| 21:56 | <Hixie> | before i knew it was the same text as the whatwg copy and so yes, i knew it was accurate modulo the differences documented in the introduction of the whatwg spec |
| 21:56 | <Hixie> | before i knew it was the same text as the whatwg copy and so yes, i knew it was accurate modulo the differences documented in the introduction of the whatwg spec |
| 21:56 | <annevk> | the parser looks rather inconsistent |
| 21:56 | <annevk> | http://dev.w3.org/html5/spec/tokenization.html#script-data-escaped-dash-state |
| 21:56 | <annevk> | "-" (U+002D) |
| 21:56 | <annevk> | U+003C LESS-THAN SIGN (<) |
| 21:57 | <annevk> | the parser looks rather inconsistent |
| 21:57 | <annevk> | U+0000 NULL |
| 21:57 | <annevk> | http://dev.w3.org/html5/spec/tokenization.html#script-data-escaped-dash-state |
| 21:57 | <annevk> | "-" (U+002D) |
| 21:57 | <annevk> | U+003C LESS-THAN SIGN (<) |
| 21:57 | <annevk> | U+0000 NULL |
| 21:57 | <annevk> | good times |
| 21:57 | <annevk> | good times |
| 21:57 | <Hixie> | but don't worry, i'm sure the chairs know what they're doing |
| 21:57 | <annevk> | oh and the text does still say U+002D HYPHEN-MINUS |
| 21:58 | <Hixie> | but don't worry, i'm sure the chairs know what they're doing |
| 21:58 | <annevk> | oh and the text does still say U+002D HYPHEN-MINUS |
| 21:58 | <annevk> | "tab" (U+0009) |
| 21:58 | <annevk> | "LF" (U+000A) |
| 21:58 | <annevk> | "FF" (U+000C) |
| 21:58 | <annevk> | lol |
| 21:58 | <annevk> | "tab" (U+0009) |
| 21:58 | <annevk> | "LF" (U+000A) |
| 21:58 | <annevk> | "FF" (U+000C) |
| 21:58 | <annevk> | lol |
| 21:58 | <zewt> | if "the chairs" are so bored that they're fucking with stuff like that, they're pretty much declaring their uselessness |
| 21:58 | <annevk> | those are not really subtle bugs |
| 21:58 | <annevk> | those are just bugs |
| 21:59 | <zewt> | if "the chairs" are so bored that they're fucking with stuff like that, they're pretty much declaring their uselessness |
| 21:59 | <annevk> | those are not really subtle bugs |
| 21:59 | <annevk> | those are just bugs |
| 21:59 | <hober> | Any comments / suggestions on http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-158 before I submit it? (It's due by the end of the day.) |
| 22:00 | <hober> | Any comments / suggestions on http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-158 before I submit it? (It's due by the end of the day.) |
| 22:00 | <zewt> | i havn't heard that phrase since highschool |
| 22:01 | <zewt> | i havn't heard that phrase since highschool |
| 22:01 | <Hixie> | hober: details section looks fine to me |
| 22:01 | <Hixie> | hober: details section looks fine to me |
| 22:01 | <annevk> | zing |
| 22:01 | <zewt> | splittin' like it's 1998 |
| 22:02 | <annevk> | zing |
| 22:02 | <zewt> | splittin' like it's 1998 |
| 22:02 | <annevk> | hober: you have my sympathy for trying to make this thing work |
| 22:02 | <annevk> | hober: you have my sympathy for trying to make this thing work |
| 22:02 | <annevk> | hober: also, a few places spell "&object>" |
| 22:03 | <annevk> | hober: also, a few places spell "&object>" |
| 22:03 | <hober> | annevk: ooh, thanks. /me fixes |
| 22:04 | <hober> | annevk: ooh, thanks. /me fixes |
| 22:05 | <hober> | Hixie: heh, i thought you'd like that |
| 22:05 | <hober> | Hixie: heh, i thought you'd like that |
| 22:57 | <_bga> | http://blog.chipx86.com/2012/03/13/wsx-virtual-machines-in-your-browser/ |
| 22:57 | <_bga> | http://blog.chipx86.com/2012/03/13/wsx-virtual-machines-in-your-browser/ |
| 23:01 | <Hixie> | ok lineDashOffset is just frustratingly hard to specify |
| 23:02 | <Hixie> | ok lineDashOffset is just frustratingly hard to specify |
| 23:02 | <TabAtkins_> | Really? I'd think that once you have specified dashed lines without an offset, the offset is easy. |
| 23:02 | <TabAtkins_> | Just move the start point. |
| 23:02 | <TabAtkins_> | Really? I'd think that once you have specified dashed lines without an offset, the offset is easy. |
| 23:02 | <TabAtkins_> | Just move the start point. |
| 23:02 | <Hixie> | you'd think |
| 23:02 | <TabAtkins_> | Do you define dashed lines from a start point? |
| 23:03 | <Hixie> | you'd think |
| 23:03 | <TabAtkins_> | Do you define dashed lines from a start point? |
| 23:03 | <Hixie> | i define dashed lines as an algorithm you apply to a set of subpaths |
| 23:04 | <Hixie> | i define dashed lines as an algorithm you apply to a set of subpaths |
| 23:05 | <Hixie> | TabAtkins_: http://www.whatwg.org/specs/web-apps/current-work/#trace-a-path |
| 23:05 | <Hixie> | TabAtkins_: http://www.whatwg.org/specs/web-apps/current-work/#trace-a-path |
| 23:05 | <Hixie> | steps 6 to 22 |
| 23:06 | <Hixie> | steps 6 to 22 |
| 23:06 | <Hixie> | my initial idea was to just offset L in step 7, but that breaks because then i have to define how you wrap around L later |
| 23:06 | <Hixie> | which is all kinds of special cases |
| 23:06 | <Hixie> | now i'm thinking of just generating a new dash list that is suitably offset |
| 23:06 | <Hixie> | my initial idea was to just offset L in step 7, but that breaks because then i have to define how you wrap around L later |
| 23:06 | <Hixie> | which is all kinds of special cases |
| 23:06 | <Hixie> | now i'm thinking of just generating a new dash list that is suitably offset |
| 23:06 | <TabAtkins_> | 7: "line for of all lines" |
| 23:06 | <Hixie> | oops |
| 23:06 | <Hixie> | thanks |
| 23:07 | <TabAtkins_> | 7: "line for of all lines" |
| 23:07 | <Hixie> | oops |
| 23:07 | <Hixie> | thanks |
| 23:07 | <TabAtkins_> | Define the dash list to be infinite (with proper wrap-around behavior), and apply an offset. |
| 23:07 | <TabAtkins_> | I do this for repeating gradients. |
| 23:07 | <TabAtkins_> | Define the dash list to be infinite (with proper wrap-around behavior), and apply an offset. |
| 23:07 | <TabAtkins_> | I do this for repeating gradients. |
| 23:08 | <Hixie> | the problem with that is that the offset can be into half-way through one of the dashes |
| 23:08 | <TabAtkins_> | And? |
| 23:08 | <Hixie> | the problem with that is that the offset can be into half-way through one of the dashes |
| 23:08 | <Hixie> | and so you have to deal with that |
| 23:08 | <TabAtkins_> | And? |
| 23:08 | <Hixie> | and so you have to deal with that |
| 23:08 | <Hixie> | since otherwise the subsequent steps don't work |
| 23:09 | <Hixie> | since otherwise the subsequent steps don't work |
| 23:09 | <Hixie> | since they use the length of each subpart of the dash list |
| 23:09 | <TabAtkins_> | Ah, indeed, because you're defining this as explicitly iterating through the list. |
| 23:09 | <Hixie> | since they use the length of each subpart of the dash list |
| 23:09 | <TabAtkins_> | Ah, indeed, because you're defining this as explicitly iterating through the list. |
| 23:09 | <TabAtkins_> | Rather than "coloring" the stroke line with on/off state. |
| 23:09 | <Hixie> | i need to be explicit so that it's clear where line caps end up going |
| 23:10 | <TabAtkins_> | Rather than "coloring" the stroke line with on/off state. |
| 23:10 | <Hixie> | i need to be explicit so that it's clear where line caps end up going |
| 23:10 | <Hixie> | (haven't yet specced that, it goes in step 22) |
| 23:10 | <Hixie> | (haven't yet specced that, it goes in step 22) |
| 23:11 | <_bga> | are you contribute to Amaya reference web browser? |
| 23:11 | <Hixie> | "reference"? |
| 23:11 | <TabAtkins_> | _bga: ....bwuh? |
| 23:12 | <_bga> | are you contribute to Amaya reference web browser? |
| 23:12 | <Hixie> | "reference"? |
| 23:12 | <TabAtkins_> | _bga: ....bwuh? |
| 23:13 | <_bga> | iirc it was browser that idealy support web standards |
| 23:13 | <_bga> | developed by you |
| 23:13 | <TabAtkins_> | Um, what? |
| 23:14 | <_bga> | iirc it was browser that idealy support web standards |
| 23:14 | <_bga> | developed by you |
| 23:14 | <TabAtkins_> | Um, what? |
| 23:14 | <TabAtkins_> | Amaya is an old browser made by the W3C, and is largely unmaintained. |
| 23:14 | <Hixie> | amaya was a testbed browser, it never had good standards support and i don't think anyone in this channel ever worked on it |
| 23:14 | <TabAtkins_> | Amaya is an old browser made by the W3C, and is largely unmaintained. |
| 23:14 | <Hixie> | amaya was a testbed browser, it never had good standards support and i don't think anyone in this channel ever worked on it |
| 23:14 | <_bga> | ah |
| 23:15 | <_bga> | ah |
| 23:15 | <_bga> | so now we dont have ideal browser |
| 23:15 | <TabAtkins_> | We never had an "ideal" browser. |
| 23:16 | <_bga> | so now we dont have ideal browser |
| 23:16 | <TabAtkins_> | We never had an "ideal" browser. |
| 23:16 | <TabAtkins_> | I have no idea what you heard about Amaya or where you heard it, but it was never a good browser. |
| 23:16 | <TabAtkins_> | I have no idea what you heard about Amaya or where you heard it, but it was never a good browser. |