# [00:50] <Hixie> TabAtkins_: but what if the whole subpath is in an "on" segment? then i don't want to add it, because i have to leave it to get the right join
# [01:07] <Hixie> i guess you don't even need lineTos
# [01:07] <TabAtkins_> You either need to figure out where the first edge starts after the curve, or start in the middle of an edge and finish with a lineTo back to that point.
# [01:12] <TabAtkins_> I suspect the problem comes from you defining the join-drawing in the wrong place.
# [01:13] <TabAtkins_> I'm trying to verify this suspicion.
# [01:13] <Hixie> well, not so much the wrong place as in the wrong way
# [01:13] <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
# [01:14] <Hixie> then i can put all the line stuff into that algorithm
# [01:14] <Hixie> instead of implying that that algorithm exists, and having multiple things in the spec imply additional steps to it
# [01:14] <Hixie> but since i've no idea how to write that algorithm, i'm gonna stick to this current approach :-)
# [01:14] <TabAtkins_> Oh, you mean converting 'stroke' to 'fill this path by inflating the original path somewhow'?
# [01:17] <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."
# [01:18] * TabAtkins_ needs to file some spec bugs on SVG2...
# [01:18] <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
# [01:19] <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
# [01:19] <heycam> stroke the tail on the donkey :)
# [01:19] <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...
# [01:32] <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.
# [01:34] <TabAtkins_> And so, step 2 of the list introduced with "The addPathData(d) method..." is unnecessary, as no errors can ever be thrown.
# [03:30] <llrcombs> would it be a reasonable request to allow messages between Web Workers to include typed arrays?
# [03:30] <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
# [03:33] <llrcombs> oh, it looks like transferable objects do that
# [03:33] <llrcombs> is that in spec, or just a WebKit extension?
# [03:41] <MikeSmith> Hixie: ah this doesn't include the replacement of the code-point names?
# [03:42] <MikeSmith> not yet integrated that script?
# [03:49] <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."
# [03:50] <MikeSmith> scott_gonzalez: fwiw, I pushed a change to the validator sources a few hours ago that streamlines the initial install
# [03:50] <MikeSmith> it should cut down the install time considerably
# [03:52] <MikeSmith> scott_gonzalez: I hope ultimately you guys could switch to using a local instance of the validator to run your validation tests
# [03:52] <MikeSmith> it's just way better in many ways
# [03:52] <MikeSmith> e.g., it handles data-* attributes just fine without you needing to filter out the errors
# [03:54] <MikeSmith> and it is at least an order of magnitude faster than any doing it with the jing-html thing I pointed you to
# [04:05] <MikeSmith> because the only possible error you get back is "fail"
# [04:05] <MikeSmith> with no details about why it's failed
# [04:05] <MikeSmith> that is, which part is invalid
# [04:06] <MikeSmith> in contrast the way those text-content checks are implemented in validator.nu, it attempts to actually report the actual specific error
# [04:33] <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
# [04:33] <MikeSmith> I don't know which chairs said that but I would imagine othermaciej doesn't see that as a goal
# [04:34] <MikeSmith> anyway I don't want to speak for him
# [04:34] <MikeSmith> I think the decision policy was designed in good faith to enable resolution on bugs where we otherwise couldn't get agreement
# [04:35] <Hixie> if that was the goal, then it's way overengineered, and doesn't work.
# [04:35] <MikeSmith> it's just the way it's been applied, it's ended up being used as a blunt instrument
# [04:36] <MikeSmith> and massively abused by a very small number of WG participants
# [04:37] <MikeSmith> Hixie: yeah I think it's worth looking at re-engineering it
# [04:37] <MikeSmith> but pausing to do that at this point seems like something that's unlikely to happen
# [04:38] <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
# [04:38] <MikeSmith> and filing bugs piecemeal against the decision policy is not really workable either
# [04:38] <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
# [04:39] <othermaciej_> Hixie: Path having a CTM is weird
# [04:39] <Hixie> (the net result being i don't bother anymore and the w3c copy of the spec is getting more and more crazy)
# [04:39] <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.
# [04:40] <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
# [04:40] <othermaciej_> Hixie: CGPath supports transforming a (whole) path and concatenating paths
# [04:41] <othermaciej_> Hixie: that is much more logical from my POV
# [04:41] <othermaciej_> CG also has a Transform object, which makes that approach more convenient; but plausibly one could use SVGMatrix to represent an affine transform
# [04:42] <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
# [04:43] <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
# [04:43] <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
# [04:44] <othermaciej_> also addFill vs. addStroke is weird
# [04:44] <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)
# [04:45] <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
# [04:45] <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
# [04:46] <Hixie> since i knew we'd also have addStroke
# [04:46] <othermaciej_> the way CG does this is with CGPathAddPath and CGPathCreateCopyByStrokingPath
# [04:46] <Hixie> CG's approach seems to involve a lot more temporaries
# [04:46] <othermaciej_> what you call addFill to me makes more sense as addPath and is the common case
# [04:47] <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
# [04:48] <othermaciej_> your approach requires a temporary to create a path outlining the strokes of a path in any case
# [04:48] <othermaciej_> it just lets you save a temporary in the (unusual) case that you want to add that to another path
# [04:50] <Hixie> and when you add text, and a whole bunch of other cases
# [04:52] <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
# [04:53] <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
# [04:53] <Hixie> i don't really see what's confusing
# [04:53] <Hixie> it's exactly like using the canvas api today
# [05:17] <jacobolus> Hixie: I gotta say, having browsers just optimize & fix the bugs in their SVG implementations would handle a lot of this :)
# [05:18] <jacobolus> but improving canvas is nice too
# [05:20] <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
# [05:24] <jacobolus> as in, you make them and only the result stays around but not the process?
# [05:26] <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
# [05:27] <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
# [05:27] <jacobolus> which are very powerful tools for building up your own abstractions, especially when using functional or concatenative programming style
# [05:28] <jacobolus> for example, it's completely trivial to define a function which draws an ellipse
# [05:36] <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
# [05:36] <Hixie> it's one of the most-requested features.
# [05:36] <jacobolus> yes, but I would suggest these are from people who don't know how to draw an ellipse using the existing API
# [05:36] <jacobolus> which is an education problem more than anything
# [05:37] <jacobolus> you can also add star shapes, regular polygons, parallelograms with specified skew, heart shapes with various parameters, ad infinitum
# [05:37] <jacobolus> I dunno, anyway, that's not such a big deal
# [05:38] <Hixie> if we had as many requests for those as for ellipses, you may have a proposal on your hands
# [05:38] <Hixie> but we've never had any requests for those
# [05:39] <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
# [05:39] <jacobolus> then they can make whatever ellipse API they want
# [05:40] <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
# [05:41] <Hixie> but i'm certainly open to alternative proposals
# [05:41] <Hixie> the wiki page has been up for months waiting for them
# [05:41] <jacobolus> explaining element, id, label, ariaRole, parentID is going to be hard
# [05:41] <jacobolus> what's the "context's default path"?
# [05:42] <Hixie> see the spec, it's now known as the "current default path"
# [05:46] <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
# [05:47] <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.)
# [05:48] <Hixie> othermaciej_: i added new Path(path) copy constructor to the list of things to add in the misc section on the wiki
# [05:48] <othermaciej_> Hixie: I think renaming addFill to addPath and addStroke to addPathByStrokingPath would improve clarity btw, without changing semantics
# [05:48] <othermaciej_> the second name is more verbose, but it is also a much less common operation
# [05:48] <Hixie> othermaciej_: what about the equivalent *Text methods on Path?
# [05:49] <Hixie> othermaciej_: addText and addTextByStrokingPath ?
# [05:49] * Quits: ezoe (~ezoe@61-205-124-26f1.kyt1.eonet.ne.jp) (Quit: And Now for Something Completely Different.)
# [05:50] <jacobolus> Hixie: I think transforming the path by the current transformation matrix whenever you call addPath/addStroke leads to some potentially extremely confusing situations
# [05:50] <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
# [05:50] <jacobolus> Hixie: given that currently, the shapes of paths end up existing relative to teh whole canvas
# [05:50] <jacobolus> not relative to the transformation
# [05:50] <jamesr> are Paths independent of their canvas or not?
# [05:51] <jacobolus> so addStroke finds the path you'd get by tracing around the edges of the stroke, not just the original path itself?
# [05:52] <jacobolus> I agree w/ othermaciej_ re: names
# [05:52] <Hixie> othermaciej_: addPath, addPathByStrokingPath, addText, and addPathByStrokingText? i guess that works
# [05:52] <Hixie> jacobolus: not sure what you mean re the transformation stuff
# [05:52] <jacobolus> in the current canvas, changing the current transformation does nothing to the current path
# [05:52] <Hixie> if y'all like addPath, addPathByStrokingPath, addText, and addPathByStrokingText i'll use those names
# [05:53] <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)
# [05:53] <jacobolus> the transformation and teh path are orthogonal concepts
# [05:53] <Hixie> jacobolus: the transformation is used when creating teh path
# [05:53] <Hixie> jacobolus: same as the transformation on a Path is used when creating the shapes of the Path
# [05:53] <othermaciej_> btw to do that you need all the details of the line style
# [05:53] <jacobolus> correct. but if you change the transformation before you stroke/fil the path, the path doesn't change
# [05:53] <Hixie> othermaciej_: yeah, that's what i'm working on tomorrow (and earlier today)
# [05:54] <Hixie> jacobolus: right, which makes it impossible to stamp out a bunch of them without redrawing the path.
# [05:54] <Hixie> jacobolus: which is what we're trying to fix by introducing Path objects
# [05:54] <jamesr> Hixie: if you have a Path, you can fill() or stroke() it into any other Path (or context)?
# [05:54] <jacobolus> Hixie: but that's not actually a problem in practice
# [05:54] <othermaciej_> it actually doesn't make sense for Path to have a line style
# [05:54] <jacobolus> Hixie: you just define a function that draws the path
# [05:55] <othermaciej_> because stroking a path will use the context's line style, not the path's (or at least it should)
# [05:55] <jacobolus> Hixie: and then you apply some transformation, call your function, stroke, apply a different transformation, call the function again, stroke
# [05:55] <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
# [05:55] <Hixie> othermaciej_: just like stroking a path onto another path will use the target path's line style, sure
# [05:55] <jacobolus> Hixie: this is precisely the idea behind the canvas API, whose abstractions come straight down from PostScript if not earlier
# [05:56] <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
# [05:56] <Hixie> othermaciej_: happy to entertain alternatives, but this seemed the most consistent with what we have now
# [05:56] <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
# [05:56] <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
# [05:57] <othermaciej_> that's not how you usually use paths in most graphics APIs that have an object for them
# [05:57] <jacobolus> there's nothing wrong with the new style, but it's confusing to someone who knows the existing canvas API
# [05:57] <othermaciej_> the 2DContext is the thing that is weird, by copying the odd CG feature of having a context-implicit current path
# [05:57] <jacobolus> and confusing for anyone trying to learn both
# [05:57] <jamesr> well the 'current API aesthetic' is a partial subset of CoreGraphics from ~5 years ago
# [05:58] <othermaciej_> but that ends up mixing path operations with context operations
# [05:58] <jamesr> CoreGraphics had the pseudo-OpenGL style state on the context
# [05:58] <jacobolus> jamesr: sure. and comes down from PostScript 25 or whatever years ago
# [05:58] <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 :-)
# [05:58] <othermaciej_> adding context operations to the Path object exacerbates that mistake
# [05:58] <jacobolus> jamesr: the current API is really nice to use if you use a functional programming style
# [05:58] <jacobolus> or especially if you use a stack-based language like postscript
# [05:59] <Hixie> othermaciej_: so if we change addFill() to addPath(), that becomes confusingly similar to addPathData(svgPathData), what should we call the latter?
# [05:59] <othermaciej_> svgPathData is the SVG string path syntax?
# [05:59] <jacobolus> Hixie: addPathFromString or similar
# [06:02] <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
# [06:03] <Hixie> othermaciej_: addPathString() seems confusing next to addPath()
# [06:03] <othermaciej_> I think combining multiple path specs into a single Path is unlikely
# [06:03] <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?
# [06:03] <othermaciej_> sure it should be possible, but you hardly need to optimize for it
# [06:03] <jacobolus> before the Path’s shape is extracted?
# [06:03] <othermaciej_> var triangle = new Path("M 100 100 L 300 100 L 200 300 z");
# [06:03] <Hixie> jacobolus: what do you mean "inverted?
# [06:10] <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
# [06:10] <jacobolus> Hixie: but it has no equivalent of context.save() or context.restore() for transformations?
# [06:11] <othermaciej_> it's the transformation, line style, and text style methods on Path that strike me as weird
# [06:13] <Hixie> jacobolus: it has a method so you an reset the transform to whatever you want
# [06:13] <jacobolus> Hixie: yes, but there's no stack of them. which makes it dramatically less powerful than the context version
# [06:13] <jacobolus> unless you keep track of the transform manually
# [06:13] <Hixie> well yeah, it's not like you're going to be doing much with them
# [06:14] <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
# [06:14] <jamesr> or if we had a separate notion of a transform stack, perhaps
# [06:14] <othermaciej_> that is certainly what seems natural to me
# [06:14] <Hixie> jamesr: how would you create a path that had another path stamped in four locations?
# [06:14] <othermaciej_> that plus an ability to one-shot apply a transform (either to a whole path, or it would return a new transformed path)
# [06:14] <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"
# [06:15] <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
# [06:15] <Hixie> othermaciej_: i guess we could have a method that takes an SVGMatrix and transforms the path to it
# [06:15] <othermaciej_> you can store a path and draw it repeatedly
# [06:15] <othermaciej_> that's the main power that is added
# [06:15] <jamesr> Hixie: subPath = new Path(); parent = new Path(); parent.fillPath(subPath, transformA); parent.fillPath(subPath, transformB); parent.fillPath(subPath, transformC); parent.fillPath(subPath, transformD);
# [06:15] <Hixie> othermaciej_: not sure what we'd do for the line styles though
# [06:16] <jacobolus> and just about as fast, since the slow part is typically the fill/stroke, rather than creating the lines themselves
# [06:16] <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
# [06:17] <jacobolus> dashed lines are a really nice addition though!
# [06:17] <jacobolus> doing those manually is a huge pain
# [06:17] <othermaciej_> interestingly, the CG AddPath operation lets you pass a transform
# [06:17] <othermaciej_> along the lines of what jamesr suggests
# [06:18] <jacobolus> and regions are nice too, though the API seems complex
# [06:19] <jamesr> it might also be nice to be able to map the points on a Path through some transform in-place
# [06:19] <jamesr> although i guess that's just a matter of making a new path and fillPath()ing it
# [06:20] <jamesr> oh, that'd just be path.addFill(path, transform)
# [06:20] <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
# [06:20] <jamesr> wait nope, misread the algo. anyway, that's probably less
# [06:21] <othermaciej_> NSBezierPath has a transformUsingAffineTransform: method
# [06:25] <jacobolus> would have to be relative to some origin point, which I suppose would be fairly arbitrary
# [06:25] <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
# [06:26] <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
# [06:26] <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
# [06:27] <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
# [06:28] <jacobolus> [along a straight edge that is]
# [06:28] <othermaciej_> you would have to calculate the outline of the stroke and fill it
# [06:28] <othermaciej_> to do fake 3D with 2D APIs
# [06:28] <jacobolus> right. "manually implement all the strokes as fills"
# [06:28] <othermaciej_> btw, supporting perspective transforms is not invisible to those who do not use it
# [06:28] <othermaciej_> it imposes memory/perf cost
# [06:29] <othermaciej_> because your representation of a transform has to be 4x4 instead of 2x3
# [06:29] <jacobolus> really? I thought graphics hardware was designed for multiplying square matrices!
# [06:31] <jacobolus> jamesr: but the whole point of using a matrix is so that you can just use matrix multiplications
# [06:31] <jamesr> and a matrix multiplication is a bunch of component multiplications. if you don't have some of those components, you can ignore 'em
# [06:32] <jacobolus> yeah, but they aren't ignored at the openGL layer I don't think
# [06:33] <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
# [06:33] <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
# [06:34] <jacobolus> I thought modern graphics hardware could do some ungodly number of matrix multiplications per second
# [06:34] <jamesr> true, but it's still not infinity
# [06:34] <jamesr> and you have to store those numbers and transfer them
# [06:34] <jacobolus> far outstripping the actual speed of drawing stuff to the screen
# [06:34] <othermaciej_> lemme put it this way; in WebKit, a 2D affine transform is 6 doubles, and a 3d perspective transform is 16 doubles
# [06:35] <jamesr> you can definitely be vertex-shader bound
# [06:35] <jacobolus> othermaciej_: sure, but it could be 9 doubles if you wanted
# [06:35] <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
# [06:35] <jamesr> or memory bandwidth bound if you have a lot of geometry and lots of matrices
# [06:35] <jamesr> 3x3 is a big cost compared to the payoff
# [06:35] <othermaciej_> but if it is true, I should file a bug
# [06:36] <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)
# [06:37] <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
# [06:38] <jacobolus> if you use a 3x4 matrix, you can specify affine transform in 3d + translation
# [06:38] <jacobolus> and you just pass 4x4 matrix, because you might as well at that point, but that last row is typically not used
# [06:39] <jacobolus> [but you could use the last row to do some really weird fun stuff!]
# [06:39] <jamesr> for 3d css we have to handle real perspective
# [06:40] <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
# [06:41] <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
# [06:41] <jacobolus> where it's completely obvious
# [06:42] <jacobolus> anyhow, it would be kind of neat to get faux-3-d in canvas, but it's not strictly necessary
# [06:43] <jacobolus> it would also be really nice to have some fast functions for doing various matrix math implemented in all the browsers
# [06:44] <jacobolus> [anyhow, sorry to have somewhat derailed the conversation. wasn't trying to do that :)]
# [06:48] <jamesr> i think having efficient implementations of common matrix ops falls under the various matrix API proposals floating 'around
# [06:48] <jacobolus> othermaciej_, jamesr: here's an example of using a functional-code-style approach to the canvas http://jsfiddle.net/x9rUN/2/
# [06:49] <jacobolus> [albeit a fairly trivial one]
# [08:01] <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
# [08:02] <jacobolus> maybe "functional" doesn't quite work as a word for that, but hey
# [09:50] <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"
# [09:50] <zcorpan> even though the former works unquoted and the latter doesn't
# [09:54] <zcorpan> i guess this is a topic matjas could write about
# [09:55] <matjas> I’m intrigued (also: mind = blown)
# [10:00] <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
# [10:00] <zcorpan> matjas: since id and class also are identifiers
# [10:02] <zcorpan> that and keywords aren't allowed as unquoted font family names
# [10:30] <MikeSmith> and it's not going to his the coast for until another 20 minutes from now
# [10:30] <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? :-)
# [11:17] <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."
# [11:20] <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
# [12:17] <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)
# [12:18] <Philip`> so they're not designed for doing anything with matrices or even with vectors
# [12:18] <jacobolus> Philip`: what about when you say "here's a transformation matrix and here are points a, b, c, d in space", etc.?
# [12:19] <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)
# [12:21] <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
# [12:24] <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)
# [12:27] <Philip`> (other than the obvious things like the OpenGL ES 2.0 spec and delta spec)
# [12:27] <jacobolus> how much of that transfers to webgl?
# [12:27] <jacobolus> I haven't taken much serious look at webgl
# [12:27] <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
# [12:28] <Philip`> so I don't know what's a good place to look
# [12:29] <jacobolus> do you know if it's possible to use WebGL just for fast computation on the GPU, and not for showing anything?
# [12:29] <Philip`> I've never really used WebGL, so I could be mistaken, but I believe it's very close to GLES2
# [12:30] <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
# [12:31] <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
# [12:40] <jacobolus> Philip`: can it be coaxed into doing the same kind of math?
# [12:40] <jacobolus> or does that require going ⇔ the CPU
# [12:41] <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 --."
# [12:44] <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
# [12:51] <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
# [13:05] <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"
# [13:06] <MikeSmith> matjas: yeah there is lots of stuff like what zcorpan mentions
# [13:06] <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
# [13:07] <MikeSmith> DTDs have some simple dataypes too
# [13:07] <MikeSmith> for constraining the values of attributes
# [13:07] <zcorpan> short version is that DTDs suck and you shouldn't care about them
# [19:27] <StoneCypher> is there a field intended for universal per-language text replacement (i18n string tables), or should i be making a data-foo attribute
# [19:30] <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
# [19:31] <Philip`> so it doesn't provide any specific support for that
# [19:36] <StoneCypher> would you think data-i18n a logical field name?
# [19:39] <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
# [22:01] <AryehGregor> Seems like a bug in Firefox/IE.
# [22:01] <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.
# [22:02] <AryehGregor> In a display: none iframe, is the viewport defined?
# [22:03] <AryehGregor> CSS 2.1 (of course) doesn't say that I see.
# [22:06] <annevk> AryehGregor: never really considered display:none iframes :/
# [22:07] <annevk> AryehGregor: it makes some sense to me that scrolling would not work there
# [22:07] <AryehGregor> It's probably more convenient for authors if it does, and more convenient for implementers if it doesn't.
# [22:08] <StoneCypher> should contenteditable=false inside a contenteditable=true region work?
# [22:08] * StoneCypher can't decide if he's doing something braindead or if the browsers aren't behaving as one would like
# [22:08] <AryehGregor> StoneCypher, yes. Browsers are known to have major bugs in this area, though.
# [22:08] <AryehGregor> Also, exactly what it should do is somewhat questionable.
# [22:08] <AryehGregor> My spec says one thing, browsers do all sorts of things.
# [22:09] <annevk> AryehGregor: it would be consistent with display:none on overflow:scroll frames if it didn't
# [22:09] <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)
# [23:04] <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