| 00:01 | <jwalden> | anyone: what browsers implement the standardized gradient syntax? gecko and ie alone? or am I missing someone? |
| 00:02 | <gsnedders> | jwalden: The CSS3 stuff? |
| 00:02 | <gsnedders> | jwalden: I believe we do. |
| 00:02 | <TabAtkins> | gecko implements a slightly older version of the syntax. webkit implements the new syntax, though with some bugs. opera and ie now implement the new syntax. |
| 00:08 | <kangax> | so... "shape" of a compositing object (in this case — an image) is what's underspecified at the moment? |
| 00:08 | <TabAtkins> | Yeah. |
| 00:09 | <TabAtkins> | If shape were properly defined, the compositing behavior is trivial. |
| 00:09 | <kangax> | should i bring it to the mailing list? |
| 00:09 | <TabAtkins> | Go ahead, though I think it's been discussed before. |
| 00:09 | <kangax> | ok, i'll check out archives |
| 00:10 | <kangax> | although... if the definition was to be specified, how will whatwg decide which one to pick? :) |
| 00:10 | <kangax> | introducing new mode would help of course |
| 00:12 | <TabAtkins> | Just add a switch, and default to the majority (global, not shape-constrained). |
| 00:12 | <jamesr> | webkit is switching to the canvas specified model for canvas 2d shortly, btw |
| 00:12 | <kangax> | oh boy |
| 00:13 | <jamesr> | meaning destination-in will clear every pixel that is fully transparent in the thingy being drawn |
| 00:13 | <jamesr> | you can get the behavior you want most of the time by setting an explicit clip |
| 00:13 | <kangax> | jamesr: explicit clip as in `clip()`? |
| 00:13 | <jamesr> | yeah |
| 00:14 | <kangax> | jamesr: that means you're confined to a set of low-level commands for creating your clipping path :) |
| 00:14 | <kangax> | instead of just drawing an image |
| 00:14 | <jamesr> | well, images have rectangular clipping regions normally |
| 00:15 | <jamesr> | so it's pretty easy to construct a clip around the image or whatever portion you want the composite operation to apply in |
| 00:15 | <jamesr> | you can also expect that most values for globalCompositeOperation other than the default are buggy in current browsers |
| 00:15 | <kangax> | oh i know |
| 00:16 | <jamesr> | but if you want to draw an image then normally you want to construct a rectangle around the image and clip() before drawing, if you only want to apply the composite operation inside the bounds of the image |
| 00:16 | <kangax> | i won't be using this behavior in any case... due to such poor "support" of it, but wanted to get to the bottom of it |
| 00:17 | <kangax> | jamesr: i don't think that would help me, since clipping region would still be rectangular (just a bounding box of an image) |
| 00:18 | <kangax> | jamesr: if i'm understanding you correctly |
| 00:18 | <jamesr> | what clipping region do you want? |
| 00:18 | <kangax> | jamesr: non-rectangular of course |
| 00:18 | <jamesr> | oh you want to use the opacity in the image? |
| 00:18 | <kangax> | yep |
| 00:18 | <jamesr> | it don't do that :) |
| 00:19 | <kangax> | webkit does :) |
| 00:19 | <jamesr> | well, only by accident |
| 00:19 | <jamesr> | it's not consistent if you use, say, gradients or patterns |
| 00:19 | <kangax> | i undestand |
| 00:20 | <kangax> | well, TabAtkins says SVG has behavior similar to what I want and it seems like a pretty common use case — just clipping something to a non-rectangular, non-vector shape (image with transparent content being perfect candidate) |
| 00:21 | <TabAtkins> | Clipping to a shape and clipping to the non-transparent regions are a bit different. |
| 00:21 | <jamesr> | you can clip to a shape in canvas |
| 00:21 | <jamesr> | but there's no notion of clipping to opacity |
| 00:21 | <kangax> | jamesr: yeah, only vector one |
| 00:21 | <TabAtkins> | You can do a <circle fill="transparent" ... /> in SVG, which will apply the compositing op to the circle even though it's transparent. |
| 00:21 | <Philip`> | Use getImageData, create a path by tracing around every non-transparent pixel, call clip() - easy :-) |
| 00:22 | <kangax> | maybe i should just do this manually |
| 00:22 | <kangax> | Philip`: was just thinking that :) |
| 00:22 | <kangax> | can only imagine the resulting performance of something like this |
| 00:24 | <kangax> | i can also probably find all transparent pixels of masking image and then "transparentize" those same pixels on canvas |
| 00:26 | Philip` | would have thought there must be an easier way to do this by drawing the image onto a large temporary canvas and then drawing that back onto the main canvas with appropriate compositing mode, to stop it depending on the inconsistent behaviour of compositing outside the source shape |
| 00:34 | <kangax> | Philip`: it's not even that — FF considers image shape to be that of a box, not its opaque content |
| 00:37 | Hixie | mumbles something abouyt 100+ post threads that have 100+ proposals and no use case descriptions |
| 00:59 | <jamesr_> | Philip`, what happens in the canvas 2d spec if you set the transform to something non-invertible, set the globalCompositeOperation, then do a draw? |
| 01:04 | <jamesr_> | it seems like firefox ignores the draw made with a non-invertible transform |
| 01:04 | <jamesr_> | instead of clearing everything |
| 01:12 | <Philip`> | jamesr_: The transform matrix only applies to the shape, before it's drawn onto the infinite transparent bitmap |
| 01:12 | <jamesr_> | so the shape should map to nothing, and then the infinite transparent bitmap is composited? |
| 01:13 | <Philip`> | The compositing is independent of transforms, so I believe so |
| 01:13 | <jamesr_> | http://software.hixie.ch/utilities/js/canvas/?c.clearRect%280%2C%200%2C%20640%2C%20480%29%3B%0Ac.save%28%29%3B%0Atry%20{%0A%20%20c.globalCompositeOperation%20%3D%20%22source-over%22%3B%0A%20%20c.fillStyle%3D%22red%22%3B%0A%20%20c.fillRect%280%2C%200%2C%20640%2C%20480%29%3B%0A%20%20c.fillStyle%20%3D%20%22blue%22%3B%0A%20%20c.fillRect%2820.5%2C%2020.5%2C%2050%2C%2050%29%3B%0A%20%20c.globalCompositeOperation%20%3D%20%22destination-in%22%3B%0A% |
| 01:13 | <jamesr_> | 20%20c.setTransform%280%2C%200%2C%200%2C%200.5%2C%200%2C%200%29%3B%0A%20%20c.fillStyle%20%3D%20%22red%22%3B%0A%20%20c.fillRect%2810.5%2C%2030.5%2C%2020%2C%2020%29%3B%0A}%20finally%20{%0A%20%20c.restore%28%29%3B%0A}%0A |
| 01:13 | <jamesr_> | firefox just ignores the draw |
| 01:13 | <Philip`> | and drawing the finite shape with e.g. scale(0,0) should presumably be about the same as drawing with scale(1e-300, 1e-300), i.e. vanishingly small |
| 01:14 | <jamesr_> | opera clears the whole world |
| 01:14 | <jamesr_> | k, seems like a firefox bug |
| 01:14 | <jamesr_> | webkit will soon clear everything |
| 01:15 | <Philip`> | My desk is still greatly cluttered, so unfortunately it doesn't clear the whole world :-( |
| 01:16 | <Philip`> | Sounds like clearing the canvas is the spec-compliant behaviour, though I think any consequences of degenerate transforms in the spec are pretty much accidental |
| 01:41 | <oojacoboo> | anyone have any input on the spec in regards to min/max widths? |
| 01:42 | <oojacoboo> | I'm finding that both firefox and chrome treat min with a higher priority than max |
| 01:42 | <oojacoboo> | actually, flat out negating the fact that max even exists |
| 01:43 | <oojacoboo> | the situation in a table is where I have min-width and max-width both applied to a <td> |
| 01:43 | <TabAtkins> | You talking about CSS min-width/max-width? |
| 01:43 | <oojacoboo> | in this case the min is the ONLY thing that even matters |
| 01:43 | <oojacoboo> | the max isn't even acknowledged |
| 01:44 | <TabAtkins> | The application of min/max to table-* elements is kinda weird. |
| 01:44 | <oojacoboo> | yes, CSS as you state |
| 01:44 | <oojacoboo> | kinda? |
| 01:44 | <oojacoboo> | bit of an understatement there |
| 01:44 | <oojacoboo> | but the fact that gecko and webkit both treat this the same is double disturbing |
| 01:45 | <oojacoboo> | I'm having an extremely hard time understanding how we can be working on things like css transitions when we can't even get something as simple as min-width/max-width finished and into the spec and implemented |
| 01:46 | <oojacoboo> | it's probably one of the more fundamental styles, especially in regards to table layouts |
| 01:46 | <TabAtkins> | Table layout is *completely* unspecified. |
| 01:46 | <TabAtkins> | The 2.1 spec offers a suggested layout algorithm, but it doesn't match any browser in the details. |
| 01:47 | <oojacoboo> | ugh! |
| 01:47 | <jamesr> | everybody thinks the thing they care about is obviously more important than everything else |
| 01:47 | <oojacoboo> | jamesr: very true |
| 01:48 | <oojacoboo> | but not being able to specify min and max widths for a table with lots of data causes unwanted wrapping results, making the data hard to read, etc |
| 01:49 | <oojacoboo> | but I hardly see how something like css transitions could take precedence over something as basic as width styling |
| 01:49 | <jamesr> | exactly |
| 01:49 | <TabAtkins> | Because table layout works well enough, and nobody wants to spend time figuring out how to specify it properly. |
| 01:49 | <jamesr> | even when this is pointed out people still insist the thing they care about is obviously more important than whatever else :) |
| 01:49 | <TabAtkins> | But transitions are sexy and cool. |
| 01:49 | <oojacoboo> | ... |
| 01:49 | <oojacoboo> | that's the problem |
| 01:50 | <TabAtkins> | It's only a problem if you think table layout doesn't work properly. Most people don't care. ^_^ |
| 01:51 | <oojacoboo> | I just want to say fuck tables and the horse they rode in on altogether at this point |
| 01:51 | <jamesr> | you also seem to think that the people who work on transitions would be working on table layout if they weren't working on transitions. that is definitely not true |
| 01:51 | <oojacoboo> | jamesr: another good point |
| 01:52 | <oojacoboo> | but seriously though, how hard is it to code up a min/max range... |
| 01:53 | <TabAtkins> | Obeying all the other implicit constraints that make up the big ball of pain that is table layout? |
| 01:54 | <oojacoboo> | TabAtkins: why would they come into play if these are specified? |
| 01:54 | <TabAtkins> | Everything comes into play when you layout tables. |
| 01:55 | <TabAtkins> | Imagine, for example, two cells that have "min-width: 100px", and a cell in another row that spans both columns and has "max-width: 150px". |
| 01:55 | <TabAtkins> | Now imagine that, rather than fully overlapping, it only partially overlaps, so you either have to ignore the constraint or find some way to fit the non-overlapping part of the cell into 50px. |
| 01:55 | <oojacoboo> | good point there, I'd fall back on the max in that case |
| 01:56 | <TabAtkins> | min-width is pretty easy, all in all. Given that table cells are BFCs, they already have implicit min-width constraints of the width of the longest word in their contents. |
| 01:57 | <TabAtkins> | Max, though, just plain hurts. |
| 01:57 | <oojacoboo> | if min-width is specified, it's the king |
| 01:57 | <oojacoboo> | and then it just does whatever it wants |
| 01:57 | <TabAtkins> | But you just said you'd honor max-width, ignoring the min-width on the other cells! |
| 01:57 | <oojacoboo> | I have multiple cells min-width: 70px |
| 01:58 | <oojacoboo> | they are spanning to 95px on their own beyond the boundaries of the table width! |
| 01:58 | <oojacoboo> | wdith: 77px !important doesn't even fix it |
| 01:59 | <oojacoboo> | ... |
| 01:59 | <oojacoboo> | width* |
| 02:00 | <oojacoboo> | I see the issues you present, but how to you explain that ^^ behavior? |
| 02:00 | <oojacoboo> | s/to/do |
| 02:00 | <TabAtkins> | I don't. Like I said, table layout is unspecified. ^_^ |
| 02:00 | <TabAtkins> | Also, I'm out for the day. |
| 02:00 | <oojacoboo> | later |
| 03:15 | <cgcardona> | thought I'd show this around in here in case anyone has any tips. https://audiofile.cc/ |
| 03:37 | <erlehmann> | cgcardona, LOL INTERNET. have you read the lilypond paper on why music is not really something representable with XML? |
| 03:37 | <erlehmann> | also, can you show me a demo? i cannot seem to find one. |
| 03:39 | <cgcardona> | erlehmann: no please post the link. The code you see at the top as well as the canvas are a live example |
| 03:39 | <cgcardona> | it's a new idea so thats the only example I have worth showing. After I get chords as well as sharps implemented i want to get some examples that change the notes with clicks and such |
| 03:44 | <erlehmann> | cgcardona, it might be this http://lilypond.org/doc/v2.12/Documentation/user/lilypond-learning/Background.html |
| 03:44 | <erlehmann> | the lilypond people may have stuff you might wish to use :) |
| 03:45 | <cgcardona> | i'll check it out. thanks |
| 06:22 | <Akilo> | saluton amikoj |
| 08:13 | zcorpan | notes that only FOs were filed as bugs |
| 08:14 | <zcorpan> | if somebody had a different argument and voted No or Abstain, maybe repeat the argument in a bug? |
| 09:34 | <hsivonen> | mysterious. The ICU-based check for max week of a year always seems to return 52 |
| 09:35 | <jgraham> | zcorpan: No surprise there then |
| 11:01 | <asmodai> | hahah, that ihatexml.py in html5lib XD |
| 11:09 | <hsivonen> | still no editing action in the rel registry |
| 11:10 | <hsivonen> | I wonder if that's going to change once MikeSmith redeploys the back end of validator.w3.org |
| 11:17 | <gsnedders> | asmodai: jgraham is the wittiest of men. |
| 11:17 | <asmodai> | gsnedders: Given the contents of the file I think the name is aptly chosen. |
| 11:25 | <zcorpan> | based on google search suggestions for "is <char>", a lot of people are searching for "is <person> gay" |
| 11:27 | <jgraham> | zcorpan: Wow |
| 11:27 | <jgraham> | f is the first letter where I didn't get at leats one suggest matching that pattern |
| 11:28 | <jgraham> | Although I did get "is fish meat" |
| 11:28 | <jgraham> | So I am a little concerened with the general intelligience of people using Google |
| 11:28 | <zcorpan> | where as "are <char>" seems to mostly end with "real" and "good for you" |
| 11:28 | <zcorpan> | jgraham: try "is g" :) |
| 11:31 | <jgraham> | Honestly the pattern is so widespreaed I suspect people gaming the results for giggles |
| 11:32 | <zcorpan> | or people are really interested in whether other people are gay |
| 11:33 | <jgraham> | I suppose that is possible |
| 11:34 | <zcorpan> | time to donate blood plasma |
| 12:15 | <hsivonen> | hmm. Why does V.nu have unused floating point datatypes? |
| 12:17 | <Philip`> | Maybe because the spec used to have floats until they got changed to doubles? |
| 12:23 | <hsivonen> | has the spec changed back and forth as far as exponent allowability on input type=number goes? |
| 12:24 | <hsivonen> | I can't believe the validator has been wrong for 4 years with the correct code in the codebase as dead code |
| 12:24 | hsivonen | can't be bothered to do full version control archeology research |
| 12:29 | <hsivonen> | I'm rather shocked by the state of float handling in the validator |
| 12:30 | <hsivonen> | it looks like I almost fixed this stuff in 2007 and then forgot to take all the remaining steps |
| 12:30 | <hsivonen> | it's also possible that Hixie has had something too crazy in the spec at a critical moment |
| 12:46 | <hsivonen> | seriously, it's 2011 and we still get stuff like this in a spec: http://www.w3.org/WAI/PF/aria/complete#valuetype_number |
| 12:50 | <hsivonen> | why does the PFWG ask me to state if I'm commenting on behalf of an organization and if the org is a W3C group, Member org or other? |
| 12:51 | <Philip`> | Isn't http://www.w3.org/WAI/PF/aria/complete#typemapping the more relevant definition of "number"? |
| 12:51 | <gsnedders> | hsivonen: Because a comment from some W3C member could turn into a vote against the spec at PR at the AC level? |
| 12:52 | <gsnedders> | hsivonen: What would you rather the abstract model defined a number to be? |
| 12:54 | <Philip`> | http://www.w3.org/WAI/PF/aria/complete#valuetype_number seems plausible as a definition of what XML Schema calls the value space, although then the problem is the value space can't be represented by the lexical representations listed in http://www.w3.org/WAI/PF/aria/complete#typemapping |
| 12:54 | <Philip`> | (since they only do finite decimal numbers, not all real numbers) |
| 12:54 | <Philip`> | but that's being a bit picky |
| 12:56 | <hsivonen> | Filed http://www.w3.org/WAI/PF/comments/details?comment_id=357 |
| 12:58 | <gsnedders> | hsivonen: I think that section just defines the abstract ARIA model, not specific to any syntax. |
| 12:58 | <hsivonen> | Philip`: OK. so the spec fails by not linking to that section |
| 12:58 | <hsivonen> | gsnedders: I see. I don't like this abstract stuff. |
| 12:58 | <Philip`> | hsivonen: That subsubsection says "These are generic types for states and properties, but do not define specific representation. See State and Property Attribute Processing for details on how these values are expressed and handled in host languages." |
| 12:59 | <Philip`> | which links to http://www.w3.org/WAI/PF/aria/complete#state_property_processing which links to http://www.w3.org/WAI/PF/aria/complete#typemapping |
| 12:59 | <hsivonen> | Philip`: ok. |
| 12:59 | <Philip`> | (though it says it's non-normative) |
| 12:59 | <hsivonen> | well, evidently, this is a readability failure |
| 13:02 | <gsnedders> | hsivonen: Well, really, it's no worse from an abstraction POV than HTML5, which only clearly defines the element definitions as abstract in one or two easy to miss places |
| 13:05 | <Philip`> | The undefinedness of how to lexically represent e.g. the aria-valuenow property with value 1/3 isn't great, but at least it's trying, whereas HTML5 only defines the mathematical concept of numbers as the consequence of a 140-word paragraph (and then defines a parsing algorithm that gives a different result) |
| 13:25 | <hsivonen> | huh. Hixie has allowed capital E as the exponent separator at some point... |
| 13:27 | <gsnedders> | hsivonen: Consistency with what ES5 allows in ToNumber |
| 15:51 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=12739 oooh ipv6 address |
| 16:47 | <MikeSmith> | recommendations for a perl module for parsing e-mail messages? |
| 16:48 | <Ms2ger> | My recommendation would be not to use perl :) |
| 16:48 | <jgraham> | Or to parse email messages |
| 16:48 | <Rik`> | Peter`: hey, I remember you have tools to check mozilla and webkit repositories? |
| 16:48 | <Ms2ger> | jgraham, ssh, I want him to parse them :) |
| 16:49 | <MikeSmith> | if perl's good enough for Hixie, it's good enough for me |
| 16:50 | <MikeSmith> | if there's a decent bugzilla library for python, I'd rather write it in python instead |
| 16:51 | <MikeSmith> | but I couldn't find any python bugzilla library |
| 16:51 | <Philip`> | Surely the solution to any parsing problem is regexps |
| 16:52 | <Peter`> | Rik`: Just WebKit and Chromium |
| 16:52 | <Rik`> | Peter`: are they public tools ? |
| 16:53 | <Peter`> | http://peter.sh/data/last-week/webkit/2011-20-monday.html |
| 16:53 | <Peter`> | http://peter.sh/data/last-week/chromium/2011-20-monday.html |
| 16:53 | <Philip`> | MikeSmith: Are these emails from random users that might be malformed etc? |
| 16:53 | <Peter`> | They're hardly tools, just a more convenient list of changesets |
| 16:53 | <Ms2ger> | I think Mozilla has python tools for interacting with bugzilla, but I don't know if the W3C instance has BZAPI set up |
| 16:53 | <Ms2ger> | Philip`, emails to public-html-comments |
| 16:53 | <MikeSmith> | Philip`: yeah |
| 16:54 | jgraham | always wonders if bzapi is a intentional reference to bz-the-person |
| 16:54 | <Philip`> | (It looks like stuff like Email::Simple might be nice enough but it says "you cannot expect it to cope well as the only parser between you and the outside world" which presumably isn't ideal here) |
| 16:55 | <MikeSmith> | Philip`: OK |
| 16:55 | Philip` | has no personal experience of anything other than piping strings into sendmail, though |
| 16:55 | <MikeSmith> | Ms2ger: I don't think it does have BZAPI set up |
| 16:55 | <Ms2ger> | jgraham, not afaik |
| 16:56 | <Ms2ger> | MikeSmith, I'd argue that's your first step, then :) |
| 16:56 | <Rik`> | Peter`: that's exactly what I'm looking for, a more convenient way to list mozilla changesets |
| 16:56 | <jgraham> | Ms2ger: Surely I can't be the only person who thinks of that when I see it though :) |
| 16:56 | <MikeSmith> | Ms2ger: it just exposes a REST API anyway, right? |
| 16:56 | <MikeSmith> | not bound to python clients |
| 16:56 | <Ms2ger> | Yep |
| 16:57 | <jgraham> | Isn't the first step to upgrade to a newer bugzilla? Tht would solve lots of problems, right? |
| 16:57 | <MikeSmith> | sure |
| 16:57 | <MikeSmith> | and probably introduce a lot of others |
| 16:57 | <Peter`> | Rik`, I may have a look in setting this up for Mozilla as well, but won't have any bandwidth until next wek |
| 16:57 | <Peter`> | week* |
| 16:57 | <Ms2ger> | (https://github.com/toolness/pybugzilla, btw) |
| 16:58 | <jgraham> | MikeSmith: Maybe. But the W3C copy seems to be well behind |
| 16:58 | <MikeSmith> | jgraham: and anyway, I have to work with what I have |
| 16:59 | <Rik`> | Peter`: don't worry, I was just looking for an existing tool so I don't have to write it :) |
| 17:00 | <jgraham> | mike][inq: f you wanted an upgrade you would presiumably point out that newer versions have more aria. Tht works like a cheat code, right? :) |
| 17:00 | <jwalden> | TabAtkins: ping |
| 17:01 | <TabAtkins> | jwalden: pong |
| 17:01 | <MikeSmith> | jgraham: that's a good point, actually |
| 17:01 | <MikeSmith> | I didn't know they hard aria markup |
| 17:01 | jgraham | apologieses if he disturbed mike][inq |
| 17:02 | <jwalden> | TabAtkins: are you aware that gradients in browsers don't actually have "no intrinsic dimensions"? like, background-image: gradient; background-size: 5px; acts as though the gradient had an intrinsic aspect ratio equal to that of the background positioning area |
| 17:02 | jgraham | wonders how well dbolter gets on with bugzilla |
| 17:03 | <jwalden> | TabAtkins: which seems a bit bizarre to me, but I'm not sure if you're trying to codify reality or codify a sensible behavior |
| 17:03 | <TabAtkins> | jwalden: the gradient itself has no dimensions. The gradient, when used, acquires dimensions equal to the element's background area. |
| 17:04 | <TabAtkins> | I'm not sure whether or not background-size:5px should affect things. Maybe? |
| 17:04 | <jwalden> | TabAtkins: the way css3 says to negotiate background-size, something with no dimensions and no aspect ratio and only one dimension constrained is rendered as if for 'contain' |
| 17:05 | <jwalden> | TabAtkins: which in that case means as large as possible while holding that specified dimension fixed |
| 17:05 | <jwalden> | TabAtkins: so background-size: 5px should per current spec algorithms give you 5px by (other dimension of BPA) |
| 17:06 | <jwalden> | TabAtkins: in browsers now it gives you 5px by (whatever length gives a ratio equal to that of the BPA) |
| 17:08 | <TabAtkins> | jwalden: Okay, so I've looked at the spec again. That behavior *should* be a bug, but it's not entirely clear from the spec, because it's not well-defined how the background-properties map into the inputs to the size resolution algorithm in the Image Values spec. |
| 17:09 | <TabAtkins> | The intent is that saying "background-size:5px" will make the "specified size" input be a 5px by 5px square, which immediately wins and sets the concrete object size to 5px by 5px. |
| 17:09 | <jwalden> | seems pretty clear to me how they map into the background-size algorithm in css3 b&b |
| 17:09 | <jwalden> | which takes as inputs only intrinsic width/height/aspect ratio |
| 17:13 | <jwalden> | fwiw I encountered this because I was implementing the css3 background-size algorithm for images partially or completely lacking intrinsic dimensions |
| 17:14 | <jwalden> | and the change to make gradients have no intrinsic ratio tripped a couple tests we have that expect the current behavior, rather than the one css3 b&b + images seems to specify |
| 17:15 | <TabAtkins> | I do need to resolve precisely where background-size sits in the size resolution order. |
| 17:24 | <TabAtkins> | jwalden: So, background-size actually repeats most of what's in the Image Values algorithm. |
| 17:24 | <jwalden> | that's possible |
| 17:24 | <jwalden> | that seems bad |
| 17:25 | <TabAtkins> | If you provide 0, 1, or 2 dimensions, the behavior is identical to the Image Values algorithm, with the dimensions being the "specified size". |
| 17:25 | <jwalden> | seems like images should delegate to css3 b&b for background-size, which *does* actually have a specified algorithm |
| 17:25 | <jwalden> | unlike <img> or <object> |
| 17:25 | <TabAtkins> | It should be the other way around, actually. Image Values has the generic algorithm that everyone uses. |
| 17:25 | <TabAtkins> | But the B&B module was written before I wrote that algorithm, thus the current state of affairs. |
| 17:26 | <TabAtkins> | But anyway, the current behavior (where the gradient takes the ratio of the box as its intrinsic ratio) is a bug. |
| 17:26 | <TabAtkins> | It should size itself to the background-size box. |
| 17:26 | <jwalden> | wait |
| 17:26 | <jwalden> | so gradients *have* intrinsic dimensions then? |
| 17:27 | <TabAtkins> | no |
| 17:27 | <jwalden> | I guess I'm just confused how images would have anything more than a width (maybe), a height (maybe), and proportions (maybe) |
| 17:28 | <TabAtkins> | That is all they have, which means we're miscommunicating somehow. |
| 17:30 | <jwalden> | well, a gradient indicated by linear-gradient(...) has more than that somehow, because it has a different width/height/ratio depending on the context that uses it |
| 17:30 | <jwalden> | and the goal was, I thought, to make gradients a special case of images writ generally |
| 17:30 | <TabAtkins> | That's completely expected. You use a gradient as a background on a 200x100 box, the gradient will be resolved into a 200x100 image. |
| 17:31 | <TabAtkins> | This is described by the sizing algorithm. |
| 17:31 | <TabAtkins> | Background-size *should* affect that computation, so writing "width:200px; height:100px; background-size:5px;" should resolve it into a 5x100 image. |
| 17:31 | <jwalden> | so "Gradients have no intrinsic dimensions." in 5. Gradients is just flat-out wrong? |
| 17:32 | <jwalden> | wait |
| 17:32 | <TabAtkins> | No, it's correct. I'm not sure what we're confusing each other over. ^_^ |
| 17:32 | <jwalden> | background-size: 5px is b-s: 5px auto, which means the height is chosen to preserve the proportions of the image |
| 17:32 | <jwalden> | which for a gradient that ostensibly is 200x100 means you'd have 5px 2.5px rendered |
| 17:33 | <TabAtkins> | Yes. But gradients have no proportions before resolution, so it instead drops down to taking the height of the sizing area. |
| 17:33 | <TabAtkins> | You're confusing yourself by thinking about things in the wrong order. |
| 17:33 | <jwalden> | so, this idea of an image that doesn't have proportions, then does, is what's not represented by b&b |
| 17:33 | <TabAtkins> | You're imagining it goes "set size of element" -> "resolve gradient size" -> "apply background-size". |
| 17:35 | <TabAtkins> | jwalden: Well, it's unclear in B&B, because such a thing didn't exist at the time. |
| 17:35 | <jwalden> | I don't think I'm imagining anything -- I'm simply reading b&b which says that the size of the background is determined by consulting the specified background-size, then resolving any auto/contain/cover using the intrinsic dimensions width, height, and ratio of the image |
| 17:35 | <TabAtkins> | ...yes? That's correct, and consistent with what I've been saying. |
| 17:35 | <jwalden> | which exist independent of context, as part of the image itself |
| 17:35 | <TabAtkins> | Can you give me a situation that you believe is resolving incorrectly? |
| 17:38 | <jwalden> | 200x100 box, with gradient, background-size: 20px auto; 1) width is 20px as specified; 2) "An ‘auto’ value for one dimension is resolved by using the image's intrinsic ratio and the size of the other dimension, or failing that, using the image's intrinsic size, or failing that, treating it as 100%." => no intrinsic ratio to consult, no intrinsic size, fail to treating as 100% 3) rendered... |
| 17:38 | <jwalden> | ...size is 20px by 100px |
| 17:38 | <TabAtkins> | Yes, that's entirely correct. |
| 17:38 | <TabAtkins> | What part of that do you think is inconsisten with what I've said? |
| 17:38 | <jwalden> | I don't |
| 17:39 | <jwalden> | so I'm confused about how we're disagreeing, then, because I thought we were somehow |
| 17:39 | <TabAtkins> | We aren't. ^_^ |
| 17:39 | <jwalden> | well then! |
| 17:39 | <jwalden> | glad that's settled |
| 17:39 | <TabAtkins> | Violent agreement it is! |
| 17:40 | <TabAtkins> | And, important note, the gradient itself is rendered into a 20x100 box, so color-stop positions done as lengths are resolved against that. They're not resolved against a 200px-wide box and then scaled down to 20px-wide. |
| 18:55 | <bga_> | omg chome has --allow-all-activex flag |
| 18:55 | <bga_> | %) |
| 19:32 | <hsivonen> | krijnh: it seems that the yellow highlights and the hiding of joins/parts is broken again |
| 20:03 | <Hixie> | ifette: yt? |
| 20:03 | <ifette> | hey |
| 20:03 | <ifette> | Hixie: yes |
| 20:03 | <Hixie> | hey |
| 20:03 | <Hixie> | are the protocol updates ready? |
| 20:04 | <Hixie> | our respective chairs are getting all antsy |
| 20:04 | <Hixie> | dunno why they get to be antsy, but it is what it is |
| 20:04 | <ifette> | Hixie: there's a few other changes that need to make it out in -08, e.g. reviews that came in from the TSV area director, some changes around ping/pong, etc |
| 20:04 | <ifette> | I have a draft that incorporates hooks for you already |
| 20:04 | <ifette> | but there's a bit more work before it can be called -08 |
| 20:04 | <Hixie> | cool, that'll work |
| 20:04 | <ifette> | i will send it to you via email |
| 20:05 | <Hixie> | thanks |
| 20:05 | Hixie | doesn't really care about version numbers :-) |
| 20:07 | <ifette> | Hixie: it's sent. I need to run, have a lunch meeting. |
| 20:07 | <Hixie> | later |
| 20:07 | <Hixie> | thanks |
| 20:07 | <ifette> | I think I defined everything (including how to send and receive data, sigh) |
| 20:08 | <ifette> | afk |
| 20:08 | <Hixie> | ok let's see if i can find the things i was supposed to update! |
| 20:10 | <Hixie> | aha, i have a folder for websocket issues |
| 20:10 | <Hixie> | perfect |
| 20:14 | <Ms2ger> | Hixie, our implementers are getting antsy too ;) |
| 20:15 | <Hixie> | they have a valid reason to be antsy |
| 20:16 | <smaug____> | Ms2ger: if you saw my bug comment, I was truly just wondering where the discussion about API changes is happening. Since I don't recall such emails in WebApps |
| 20:17 | <Ms2ger> | Didn't mean to suggest anything else |
| 20:18 | <smaug____> | well, Hixie might know where the discussion about changes to WebSocket API is happening :9 |
| 20:18 | <smaug____> | :) |
| 20:18 | <Ms2ger> | In his IMAP folders? :) |
| 20:19 | <Hixie> | whatwg, webapps, and w3c bugzilla |
| 20:21 | <smaug____> | Hixie: sicking mentioned something about adding open() |
| 20:21 | <smaug____> | I can't really find any email about that |
| 20:21 | <sicking> | smaug____: have you looked at the bug? |
| 20:21 | <Hixie> | i have no plans to add open(), but there have been some mails about it |
| 20:21 | <Hixie> | i haven't yet read all the feedback though |
| 20:21 | <smaug____> | sicking: ah, you're awake! |
| 20:22 | <Hixie> | so maybe there is some reason to add it that i am not yet aware of |
| 20:22 | sicking | is in meeting |
| 20:22 | <smaug____> | oh, right, I'm not in EET, atm |
| 20:22 | <sicking> | Hixie: last i looked, binary data and redirects were easier if we had .open |
| 20:22 | <Hixie> | (so far the only argument i've seen is "you can't hook the event listeners before the events fire if you don't have open()", which is false) |
| 20:22 | <Hixie> | sicking: i look forward to coming across the relevant feedback :-) |
| 20:23 | <Hixie> | i can't see how it would affect either of those, but i'm certainly happy to find out |
| 20:23 | <sicking> | Hixie: for binary data, you want to choose which format you want the result (blob or arraybuffer) |
| 20:23 | <sicking> | Hixie: which you can do after opening, but you risk the UA wasting time converting |
| 20:24 | <Ms2ger> | Hixie, if you had time to look at http://www.w3.org/Bugs/Public/show_bug.cgi?id=12742 , that would be nice |
| 20:24 | <Ms2ger> | (Turns out someone is implementing meter) |
| 20:24 | <Hixie> | Ms2ger: on it |
| 20:24 | <smaug____> | sicking: couldn't you just give all that information as parameters to ctor? |
| 20:24 | <Hixie> | sicking: why would the UA spend any time converting? surely the behind-the-scenes storage is identical |
| 20:24 | <Hixie> | sicking: my plan was to just expose both |
| 20:25 | <sicking> | smaug____: sure, but that means there's two APIs for choosing format. You need the ability to change format after receiving messages |
| 20:25 | <smaug____> | aha |
| 20:25 | <smaug____> | ok, I thought there would be one socket for each type |
| 20:25 | <sicking> | Hixie: if we first store to a blob, and then the page says "i want array buffers", we wasted time streaming to disk and then reading back into memory |
| 20:25 | <Hixie> | (for each message, just do .getDataAsBlob() or .getDataAsArrayBuffer() or whatnot and once you've done it the shop is closed and that's it) |
| 20:25 | <Hixie> | sicking: why would you stream to disk? |
| 20:25 | <Hixie> | sicking: just have the blob be memory-backed |
| 20:26 | <sicking> | Hixie: if you're receiving a huge thing |
| 20:26 | <Hixie> | why would the size matter |
| 20:26 | <Hixie> | you just memory map something that can be paged out |
| 20:26 | <sicking> | the whole reason you'd ever want to use blobs at all, is that the data is so large that you would rather not keep it in memory |
| 20:26 | <sicking> | that's the only reason you'd ever use a blob with websocket |
| 20:26 | <sicking> | or XHR |
| 20:27 | <Hixie> | whether it's in the ram chips or the disk cache or the disk or any number of other places seems like something the OS should take care of |
| 20:27 | <Hixie> | you just give the OS the pile of data, ask for some address space for it, and let it figure it out |
| 20:27 | <sicking> | Hixie: no, you don't want to have the same API for managing 4 bytes as for 4MB |
| 20:27 | <Hixie> | Ms2ger: in what sense is it ambiguous? i don't follow the bug. |
| 20:28 | <sicking> | Hixie: that's the same reason we have different APIs for <video> and <img. |
| 20:28 | <sicking> | <img> |
| 20:28 | <sicking> | you need to think differently when you handle large amounts of data |
| 20:28 | <Hixie> | we have different apis for <video> and <img> because <video> can be stopped and started and <img> can't |
| 20:28 | <Hixie> | not because they are different sizes |
| 20:28 | <sicking> | i disagree |
| 20:28 | <Hixie> | as the person who wrote the api, i am pretty sure i'm confident of the reasoning that led to the api :-) |
| 20:29 | <sicking> | Hixie: the buffering APIs on <video> has nothing to do with start/stop |
| 20:29 | <Hixie> | well sure, there's nothing to buffer for <img>, you always have to show all of it |
| 20:29 | <sicking> | right |
| 20:29 | <Hixie> | what's that got to do with 4 bytes vs 4 MB? |
| 20:29 | <Hixie> | if the 4MB is a PNG, you need all of it |
| 20:30 | <Hixie> | if the 400 bytes is a WebM video, you can use buffering APIs |
| 20:30 | <sicking> | so my point is that if you want to be able to manage large amounts of data, you need separate APIs for doing so efficently |
| 20:30 | <Hixie> | i don't think the size is the important factor here |
| 20:30 | <sicking> | if we had the same APIs for managing Blobs as for say Strings, people will write more inefficient code |
| 20:31 | <Hixie> | Strings vs Blob is a red herring, since the difference there is one of encodings |
| 20:31 | <Hixie> | Blob vs ArrayBuffer is the better comparison |
| 20:31 | <Hixie> | and the difference there is just what you're goign to do with it, not the size |
| 20:31 | <sicking> | that doesn't make it a red herring |
| 20:32 | <sicking> | there are multiple differences I agree |
| 20:32 | <Hixie> | you can have a 10 bytes Blob and a 10MB ArrayBuffer and not be doing anything wrong |
| 20:32 | <Ms2ger> | Hixie, so, what would document.createElement("meter").max return? |
| 20:32 | <Hixie> | and vice versa |
| 20:32 | <sicking> | Hixie: except that you'll likely end up with inefficent code |
| 20:33 | <sicking> | Hixie: you want APIs where expensive operations feel expensive, and cheap operations feel cheap |
| 20:33 | <hsivonen> | so now after protocol delays we are going to have API delays before Web Sockets become an unprefixed interoperable part of the Web platform? |
| 20:33 | <Hixie> | Ms2ger: 0.0 |
| 20:33 | <Hixie> | hsivonen: if by "delays" you mean "a couple of days" |
| 20:33 | <smaug____> | hsivonen: and Chrome continues to ship the non-prefixed old API/protocol |
| 20:33 | <Hixie> | sicking: sure |
| 20:34 | <Hixie> | sicking: but that's not the difference here |
| 20:34 | <sicking> | Hixie: and copying 4 bytes and 4MB takes different time |
| 20:34 | <Hixie> | sicking: Blob is about handling an opaque set of bytes, ArrayBuffer is about reading the bytes. |
| 20:34 | <Hixie> | sicking: how they are backed is an implementation concern not exposed in the API. |
| 20:34 | <sicking> | Hixie: nope |
| 20:34 | <hsivonen> | Hixie: well, let's hope it's a just a couple of days plus one six-week development cycle |
| 20:34 | <sicking> | Hixie: ArrayBuffer is opaque |
| 20:34 | <Ms2ger> | That's what I thought, but the patch returns 1.0 |
| 20:34 | <Hixie> | Ms2ger: better fix it then :-) |
| 20:34 | <sicking> | Hixie: both ArrayBuffer and Blob represent a bag of bytes |
| 20:35 | <Hixie> | sicking: a |
| 20:35 | <Hixie> | er |
| 20:35 | <sicking> | Hixie: which you can use other APIs to read from |
| 20:35 | <The_8472> | sicking, a bag does not impose ordering. an array does |
| 20:35 | <Hixie> | sicking: true, i forgot about FileReader |
| 20:36 | <sicking> | Hixie: ArrayBuffer represents a size small enough that it makes sense to keep in memory |
| 20:37 | <Ms2ger> | So, want to add, say, "(For the purposes of reflection, these attributes don't have default values.)"? :) |
| 20:37 | <Hixie> | sicking: i disagree that there is a size implication to Blob or ArrayBuffer. |
| 20:37 | <Hixie> | Ms2ger: there's like a 100 attributes in the spec to which that would apply. It would just make the spec bigger without improving its quality. |
| 20:37 | <sicking> | Hixie: may i steal your editor argument? ;-) |
| 20:38 | <Hixie> | sicking: you can certainly argue that the specs intended for there to be a difference |
| 20:38 | <Ms2ger> | K |
| 20:38 | <Hixie> | sicking: but they don't have one in the finished product |
| 20:38 | <sicking> | Hixie: they are certainly optimized for the usecase of being different size |
| 20:38 | <sicking> | Hixie: people can always abuse any API if that's what you mean? |
| 20:39 | <sicking> | Hixie: this is why ArrayBuffer allows synchronous access, but Blob does not |
| 20:39 | <Hixie> | sicking: I would agree that ArrayBuffer is more optimal for in-memory data and Blob is more optimal for data that is stored on something with high latency |
| 20:39 | <Hixie> | sicking: but that's also independent of size |
| 20:40 | <Hixie> | sicking: if i have a gig of data in RAM, and one byte of data on a tape in an automated tape cassette deck system, it's gonna be quicker to read the entire gig than the one byte |
| 20:40 | <Hixie> | sicking: and ArrayBuffer would be appropriate for the former while Blob is appropriate for the latter |
| 20:40 | <Hixie> | sicking: and not vice versa |
| 20:40 | <sicking> | Hixie: right, so erm, i'm not gonna optimize the API for that computer |
| 20:41 | <Hixie> | "that computer" is also called "the cloud" |
| 20:41 | <sicking> | your cloud is backed by a one byte tape cassette? |
| 20:42 | <Hixie> | i didn't say the cassette only had one byte |
| 20:42 | <Hixie> | i just meant that you had one byte of interest on the tape |
| 20:42 | <Hixie> | and yes, the cloud is backed by tape backup |
| 20:42 | <Hixie> | (q.v. http://gmailblog.blogspot.com/2011/02/gmail-back-soon-for-everyone.html) |
| 20:43 | <sicking> | so if you want a performant app, you should not use a ArrayBuffer that swaps to that disk |
| 20:43 | <sicking> | it'll work if you do, it'll just be slow |
| 20:44 | <Hixie> | and you shouldn't use a blob for the 1GB in-memory file, since you would have to convert the Blob to an ArrayBuffer to read it |
| 20:44 | <Hixie> | anyway i think the original argument is better expressed as "we don't want to have to keep the whole thing in memory if we don't have to" |
| 20:44 | <Hixie> | so if the author can give a hint that the data won't be immediately read, that would be a good hint to give |
| 20:45 | <sicking> | yes |
| 20:45 | <sicking> | well |
| 20:45 | <sicking> | as long as i can choose if i want the next message as an arraybuffer or a blob i'm happy |
| 20:45 | <sicking> | and we can disagree what the use cases are :) |
| 20:45 | <Hixie> | controlling the next message is probably not ideal either |
| 20:46 | <Hixie> | if the server tells you "i'm about to send a 1GB attachment" and then sends it, it might be too late by the time you process the event for the warning message to help the UA with the next message |
| 20:46 | <sicking> | so what do you propose? |
| 20:46 | <Hixie> | what you really want is a way for the script to tell the UA ahead of time which messages should be stored as Blobs and which shouldn't, or something like that... |
| 20:47 | <Hixie> | hmm |
| 20:47 | <Hixie> | do binary messages have any metadata? |
| 20:47 | <Hixie> | or as they straight binary data? |
| 20:47 | <sicking> | don't know |
| 20:47 | <Hixie> | s/as/are/ |
| 20:47 | Hixie | looks |
| 20:48 | <sicking> | i think it also depends on what the client side is going to use the data for |
| 20:48 | <Hixie> | man, this protocol got way more complicated |
| 20:48 | <sicking> | if i know that all i'm gonna do with the data is to stick it in IndexedDB, then it's nice if i can just tell the socket to give me a blob |
| 20:48 | <sicking> | this is sort of similar to the responseType property on XHR |
| 20:49 | <Hixie> | no metadata, it seems |
| 20:50 | <Hixie> | with XHR, you ask for the data ahead of time, though |
| 20:50 | <sicking> | ok, i gotta take off |
| 20:50 | <Hixie> | later |
| 20:50 | <sicking> | you are with websocket too, no? by connecting |
| 20:50 | <Hixie> | websocket is full-duplex, not request-response |
| 20:51 | <Hixie> | you don't know that the next packet you get is going to be what you last asked for |
| 20:51 | <Hixie> | it could be a random update |
| 20:51 | <sicking> | sure, i'm not sure I see the difference thoguh |
| 20:52 | <Hixie> | say you ask for a big image you want to store somewhere |
| 20:52 | <Hixie> | so you set the websocket object to give you a blob |
| 20:53 | <Hixie> | but the next message you get from the server is a binary status message |
| 20:53 | <Hixie> | and only then do you get the big image |
| 20:53 | <sicking> | well, that can easily be solved on a app level |
| 20:53 | <sicking> | just send one message saying what's about to come next |
| 20:53 | <Hixie> | by the time you are processing that message, it's too late |
| 20:54 | <Hixie> | that message and the binary data will probably all be read from the same IP packet and processed by the UA before any events are fired |
| 20:54 | <sicking> | if it's that small amount of data then it doesn't really matter though |
| 20:54 | <sicking> | the implementation can just create a memory backed blob |
| 20:55 | <sicking> | effectively the same thing happens with XHR |
| 20:55 | <Hixie> | you're going to be getting a lot of data very quickly |
| 20:55 | <sicking> | by the time you fire the HEADERS_RECEIVED event, the body will be full on streaming |
| 20:55 | <Hixie> | if the main UI thread is busy doing something like whosing an alert(), you're going to get the whole 4MB before you have had a chance to tell the script about the warning message |
| 20:56 | <sicking> | sure |
| 20:56 | <sicking> | same thing with XHR |
| 20:56 | <Hixie> | well i can't speak for XHR's design |
| 20:56 | <sicking> | the page can just choose not to put up an alert |
| 20:56 | <sicking> | this is all about giving the page the tools to manage its resources |
| 20:57 | <sicking> | it can do so well, or it can do so crappily |
| 20:57 | <Hixie> | are we talking about an API that forces teh response to be just one type, like XHR, or an API that gives a hint but doesn't preclude getting the other type? |
| 20:58 | <Hixie> | i don't think it's realistic to expect a whole event loop spin to occur fast enough after the first message is processed to be useful for the next message |
| 20:58 | <sicking> | well, if the app strings two messages together, it's got basically the same capabilities as XHR, right? |
| 20:59 | <Hixie> | i can't speak for XHR's design. As far as I can tell, allowing responseType to be set in the headers stage nullifies any implementation benefit for that API. |
| 20:59 | <sicking> | out of curiosity, what bandwidth are you envisioning? |
| 21:01 | <Hixie> | well i dunno. in some parts of the world we're still talking 24kbps, but in other parts of the world we're seeing deployment of residential terabit broadband |
| 21:01 | <Hixie> | but since the cpu is probably somewhat proportional to the bandwidth, i doubt that matters much |
| 21:02 | <sicking> | my experience is that downloading 4MB takes a lot longer than spinning the event loop a couple of times |
| 21:02 | <sicking> | but i haven't run any numbers |
| 21:03 | <sicking> | ok, taking off for real |
| 21:05 | <Hixie> | seems like the better solution is to just have the UA stream to memory at first, then past a dynamic threshold switch to streaming to disk |
| 21:06 | <Hixie> | the threshold being derived by inspection, based on the frequency with which getAsBlob() is called vs getAsBuffer() for each particular size |
| 21:06 | <Hixie> | maybe on a per-origin basis |
| 21:07 | <Hixie> | although i have to wonder, won't many protocols consist of a binary prefix saying what kind of data it is followed by something to be read as a blob? |
| 21:07 | <Hixie> | instead of a text frame followed by a binary frame? |
| 21:08 | <Hixie> | i guess the latter is easier with this api |
| 21:08 | <bfrohs> | http://bit.ly/iUaRu8 - Is it just me, or are the controls coming out red? (in chrome, fine in firefox) |
| 21:09 | <bfrohs> | And just to make sure I'm not crazy, "input" should *not* work in css for "audio" controls, correct? |
| 21:10 | <TabAtkins> | They shouldn't. But they do, because our implementation is bad right now. |
| 21:10 | <TabAtkins> | Near future, controls will be properly hidden under a shadow dom, and won't match selectors in the outer page. |
| 21:14 | <bfrohs> | TabAtkins: kaykay, thanks! |
| 21:29 | <TabAtkins> | Hixie: Just published Lists WD, a full 8.5 years after your last WD. I know that's a record in CSS; I wonder how it compares across the W3C? |
| 21:31 | <Hixie> | TabAtkins: meh, publishing WDs is so last decade |
| 21:32 | <TabAtkins> | Whatevs. |
| 21:34 | <zewt> | last decade, or, well, 8.5 years ago at any rate |
| 21:34 | <bfrohs> | TabAtkins: Section 7 Using Content as Markers: The 'marker' value for 'display'... Did you mean to have 'same as CSS2.1' listed for each property? |
| 21:35 | <TabAtkins> | bfrohs: Yes. The preprocessor that generates the property table at the end gets angry without all the values. |