| 07:51 | <hsivonen> | Somehow, I get the feeling that the treatment of longdesc and RDFa as far as reopening goes has gone into the W3C politics land instead of implementing the kind of agnostic fairness that is theoretically supposed to be applied |
| 07:52 | <hsivonen> | It's rather amusing to see the distinction between "new information" and "new research" |
| 07:55 | <hsivonen> | I'd love to see Google's Rich Snippets team respond to http://lists.w3.org/Archives/Public/public-html/2011Apr/0227.html |
| 08:38 | <hsivonen> | regarding the ARIA mapping of headings, the implied aria-level should depend on the outline algorithm, IMO |
| 08:47 | <othermaciej> | hsivonen: I'm somewhat confused about the state of the outline alrogithm |
| 08:47 | <othermaciej> | I remember there used to be a long, extremely complicated algorithm that assumes it is walking the whole document which defined the document outline |
| 08:47 | <othermaciej> | is there a defined simpler algorithm that can be applied from the point of view of an element, to determine its outline level? |
| 08:48 | <othermaciej> | because I'm definitely not up for running the algorithm in <http://dev.w3.org/html5/spec/Overview.html#outlines>; to compute accessibility API mappings... |
| 08:50 | <hsivonen> | othermaciej: if you aren't and other vendors aren't either, I think the sections and headings in HTML5 need to be redesigned ASAP |
| 08:50 | <hsivonen> | othermaciej: because it doesn't help anyone to have fictional heading depths with h1/section if they don't get exposed to AT |
| 08:51 | <hsivonen> | s/ if they / that / |
| 08:51 | <hsivonen> | othermaciej: IIRC, the algorithm was designed as a one-pass sweep |
| 08:51 | <othermaciej> | hsivonen: there might be some simpler algorithm which follows from that one which lets you look at an h1 and crawl its ancestors only to compute its heading level |
| 08:51 | <hsivonen> | and, IIRC, you could cache the state of the algorithm in the hn nodes |
| 08:52 | <othermaciej> | hsivonen: one-pass sweep of whole document is not a good design in the face of dynamic DOM updates |
| 08:52 | <hsivonen> | so upon mutation, you'd need to resweep from the last unchanged hn onwards |
| 08:52 | <othermaciej> | that sounds unbelievably bad for performance |
| 08:53 | <hsivonen> | othermaciej: I've been trying to draw attention to this for a couple of years |
| 08:53 | <othermaciej> | ah |
| 08:53 | <othermaciej> | there is a separate definition of "outline depth" |
| 08:53 | <othermaciej> | that one looks efficiently computable |
| 08:53 | <othermaciej> | http://dev.w3.org/html5/spec/Overview.html#outline-depth |
| 08:53 | <hsivonen> | "this" being that it's bad to have a something potentially perf-sensitive in the spec that isn't getting implemented in any browser |
| 08:54 | <hsivonen> | all the while it is being advertised to authors |
| 08:54 | <othermaciej> | I have always ignored the more general outline algorithm because I didn't expect it would ever be needed for any Safari features |
| 08:55 | <othermaciej> | I guess the only tricky thing about "outline depth" is whether the number of ancestor sections can be determined just by looking at its ancestor elements |
| 08:55 | <hsivonen> | othermaciej: the bit you linked to is defined in terms of the outline algorithm! |
| 08:55 | <othermaciej> | ah, and you have to know what section the heading is associated with |
| 08:55 | <othermaciej> | yeah, I didn't realize this |
| 08:55 | <othermaciej> | I misread it as something simple |
| 08:55 | <hsivonen> | the word section is the *concept* section, not the element |
| 08:55 | <othermaciej> | like, climb up DOM tree, count number of sectioning elements |
| 08:56 | <othermaciej> | that is sanely implementable |
| 08:56 | <othermaciej> | both as a selector and for ARIA purposes |
| 08:56 | <othermaciej> | but something that requires running the outline algorithm, that seems like a nonstarter |
| 08:56 | <othermaciej> | I guess I should file a bug, or get someone else at Apple who has more time to review the details to do so |
| 08:56 | <hsivonen> | my problem with trying to draw attention to this is that I don't hack on the selector engine and I don't want to make too many claims about code that I don't work on |
| 08:57 | <othermaciej> | can you review it with someone who does work on Gecko's selector engine, or its ARIA implementation? |
| 08:57 | <zcorpan> | you only need to do an outline from the closest sectioning element right? |
| 08:57 | <zcorpan> | since an explicit section will close implicit sections |
| 08:58 | <othermaciej> | what's interesting is that the rendering section uses a much simpler way of determining sizing of h1's |
| 08:58 | <othermaciej> | I would propose that ARIA heading level should use that same rule |
| 08:59 | <zcorpan> | yeah the sizes and the outline don't match up |
| 08:59 | <zcorpan> | and the sizes doesn't work nicely with <hgroup> either |
| 08:59 | <othermaciej> | (it's just number of ancestor sectioning elements) |
| 08:59 | <othermaciej> | in which case I have no need to care about the outline algorithm |
| 08:59 | <hsivonen> | I think the sizes, AT-exposed levels and the potential future selector should all be computed the same way |
| 08:59 | <othermaciej> | though it seems like it would be good to fix it to match the effect you get from the style rules |
| 09:00 | <hsivonen> | othermaciej: there's a chance that you are judging the outline algorithm as a non-started too hastily |
| 09:00 | <hsivonen> | othermaciej: considering that it has interesting cacheable points |
| 09:01 | <othermaciej> | hsivonen: there's no way the marginal features it provides over "number of ancestor sectioning elements" are worth the level of code complexity that would imply |
| 09:01 | <hsivonen> | othermaciej: I'll ping bz and dbaron to ask about review from the selector POV |
| 09:02 | <hsivonen> | I think the ARIA question gets answered as a side effect of the selector question, because selectors are more perf-sensitive |
| 09:02 | <othermaciej> | zcorpan: in the common case, the closest sectioning element is the document root |
| 09:06 | <Hixie> | the outline heading depth problem, insofar as we are talking about exposing h2-h6 to ATs in a manner that accurately honours the author's intent while being usable from the user's perspective (i.e. not dropping levels randomly) is a problem that was introduced with the very first spec of HTML, in the early 90s. |
| 09:11 | <jgraham> | Hixie: Who introduced the problem isn't really interesting :) |
| 09:11 | <Hixie> | my point is that there's not much we can do about it |
| 09:12 | <MikeSmith> | damn |
| 09:12 | <MikeSmith> | big earthquake |
| 09:12 | <Hixie> | another? |
| 09:12 | <MikeSmith> | yeah |
| 09:12 | <MikeSmith> | right now |
| 09:12 | <jgraham> | There is no reason that you couldn't run the outline algorithm backwards from an element to get the depth, but yes it could involve walking lots of the tree |
| 09:13 | <MikeSmith> | seems to have stopped now |
| 09:13 | <jgraham> | MikeSmith: Shit. Also, aren't you supposed to be under a desk or something? |
| 09:13 | <jgraham> | Not talking on IRC? |
| 09:13 | <zcorpan> | Hixie: having a selector and an outline algorithm that is good enough and with good perf is better than no selector and slightly more accurate outline algorithm |
| 09:13 | <Hixie> | jgraham: yeah in the worst case you just have to crawl backwards up to the previous h1 or sectioning element (or <body>) |
| 09:14 | <Hixie> | zcorpan: we're not talking about a selector here, but about ATs |
| 09:14 | <zcorpan> | Hixie: i thought we were talking about a selector too |
| 09:14 | <jgraham> | I think we have to talk about both |
| 09:14 | <MikeSmith> | jgraham: no real desk at my apartment, and nothing else to get underneath :) |
| 09:14 | <Hixie> | zcorpan: i was just responding to othermaciej's comment |
| 09:15 | <jgraham> | MikeSmith: Maybe step 1 is to buy a desk then :) |
| 09:15 | <hsivonen> | has anyone written a correct backwards crawl algorithm yet? |
| 09:16 | <jgraham> | hsivonen: I don't think that anyone has actually written it down |
| 09:16 | <jgraham> | hsivonen: I don't think that it is very hard though |
| 09:17 | <hsivonen> | "not very hard" is easily proven by doing it :-) |
| 09:17 | <Hixie> | it's not hard, but the worst case can be pretty bad if perf is a concern |
| 09:17 | <jgraham> | I was expecting that you would say that :p |
| 09:17 | <othermaciej> | "if perf is a concern" - yeah, who knows if browser implementors would care about that |
| 09:18 | <Hixie> | the algorithm wasn't intended for browser vendors |
| 09:18 | <Hixie> | it was intended for tools like anolis |
| 09:18 | <Hixie> | for which a single pass is fine |
| 09:18 | <jgraham> | Hixie: That seems silly |
| 09:18 | <hsivonen> | Hixie: what's the point in having anolis report different levels than AT? |
| 09:18 | <jgraham> | othermaciej: Suggestions on ways to improve perf whilst maintaing compatibility with HTML4 are welcome |
| 09:19 | <Hixie> | hsivonen: no particular point. Do ATs react dynamically to change in heading structure? |
| 09:19 | <Hixie> | hsivonen: do they even expose the heading structure? (as opposed to just exposing h1-h6 as levels 1-6 with no attempt at making it match the actual structure?) |
| 09:19 | <hsivonen> | othermaciej: browsers do implement stuff like nth-of-type, so there's precedent for "bad" selectors that aren't exercised too commonly on the Web |
| 09:20 | <hsivonen> | Hixie: I can't answer your first question, because I haven't tested AT enough |
| 09:20 | <othermaciej> | jgraham: I don't really know what "compatibility with HTML4" means in this context |
| 09:20 | <Hixie> | yeah, me either |
| 09:20 | <othermaciej> | what kind of software uses the outline algorithm? |
| 09:20 | <othermaciej> | what did it do historically for HTML4? |
| 09:20 | <hsivonen> | (and I have trouble testing AT, because I have abnormal input devices for health reasons) |
| 09:21 | <hsivonen> | (and AT assumes normal input devices. oh. the irony) |
| 09:21 | <othermaciej> | is it necessary that heading level selectors, sizing, or accessibility API reflection should be compatible with whatever legacy software did to generate outlines of HTML4 documents? |
| 09:21 | <Hixie> | hsivonen: same here :-/ |
| 09:22 | <hsivonen> | Hixie: as for the second question, if we are telling authors to use h1/section, we'd better have a realistic path for getting to a situation where AT doesn't just say "level 1" for all those |
| 09:23 | <Hixie> | hsivonen: for section/h1, the algorithms are trivial and quite performant. |
| 09:23 | <Hixie> | (they're O(N) in the depth of the tree at the node you're looking at) |
| 09:23 | <jgraham> | othermaciej: The use case is something like "an aggregation page wants to take content from various sources, some of which use <h1>-<h6> to provide headings and some of which use <section>, and get a coherent document outline that can be exposed to AT and styled in a uniform way using simple-to-author selectors" |
| 09:23 | <hsivonen> | Hixie: isn't the whole point of the generalized algorithm that you don't know a priori if you have pure h1/section? |
| 09:23 | <othermaciej> | Hixie: but you can't decide to run the algorithm only if you're in the good case |
| 09:24 | <Hixie> | sure |
| 09:24 | <jgraham> | othermaciej: Hixie's proposal is that you get wrong results except in the good case |
| 09:24 | <Hixie> | but once you hit an h1 you're fine |
| 09:24 | <Hixie> | what proposal? |
| 09:24 | <othermaciej> | I'm fine with the requirements on browsers being that you just count the number of ancestor sectioning elements |
| 09:25 | <hsivonen> | (I supposed I should have had s/AT/screen readers/ above.) |
| 09:25 | <othermaciej> | as long as no one expects browsers to implement the outline algorithm or the outline depth algorithm which depends on it, I don't really care if it's efficient |
| 09:25 | <jgraham> | Hixie: The one you made before about styling headings using CSS by counting ancesors |
| 09:25 | <Hixie> | the complicated case here is the same as you've always had to do, the only new thing we've added is section/h1, which is simple. |
| 09:25 | <Hixie> | jgraham: only <h1> headers |
| 09:26 | <jgraham> | Hixie: You still get wrong results for the use case above |
| 09:26 | <jgraham> | Where you don't control all the content |
| 09:26 | <Hixie> | for some definition of "wrong" |
| 09:26 | <Hixie> | you get the same results you've always gotten |
| 09:26 | <Hixie> | right? |
| 09:26 | <jgraham> | Previously no one has used <section> or anything |
| 09:27 | <jgraham> | So you will get worse results |
| 09:27 | <jgraham> | when people do |
| 09:27 | <Hixie> | why would they get worse results? |
| 09:27 | <Hixie> | i don't follow |
| 09:28 | <othermaciej> | Hixie: in any case, and popping the stack a few levels, I think you should put back the h1-h6 default role - the CP was ambiguous, so it seems best to interpret it the way both you and Steve think is actually better |
| 09:28 | <jgraham> | Well I guess not really worse |
| 09:28 | <Hixie> | othermaciej: the CP is ambiguous and flat out wrong about a whole bunch of stuff |
| 09:28 | <hsivonen> | anyway, if I implement an outline display for V.nu, I want to show an outline users would experience--not the outline a spec gen tool would produce (no offense to anolis intended) |
| 09:29 | <Hixie> | othermaciej: if you want me to fix the mistakes i'm happy to do so, but i'm not stopping at the one mistake faulkner happens to have noticed. |
| 09:29 | <othermaciej> | Hixie: also, if you want to blame anyone in markup comments for the ARIA decision, you should blame all the chairs, not just Sam; Sam did do the drafting, but Paul and I reviewed and signed off on it |
| 09:30 | <jgraham> | I think I agree with hsivonen. If users will never see the "true" document outline we shouldn't bother with that concept of true |
| 09:30 | <jgraham> | Since one can't meaningfully solve any problems using it |
| 09:30 | <othermaciej> | I at least take personal responsibility for it |
| 09:31 | <Hixie> | othermaciej: the markup comment is not present in the w3c html wg copy. |
| 09:31 | <othermaciej> | I know |
| 09:32 | <othermaciej> | I'm not giving you an order, I'm just making an accuracy suggestion |
| 09:32 | <Hixie> | othermaciej: if you really did review it, you did a pretty poor job. :-P |
| 09:33 | <othermaciej> | Hixie: I did indeed review it, and I read all the Change Proposals and survey comments as well |
| 09:33 | <othermaciej> | I believe that makes me equally responsible for any aspects of it, good or bad |
| 09:33 | <othermaciej> | I realize this may not be clear from the way they are posted |
| 09:43 | <hsivonen> | btw, has the iPad Safari bug that required .mp4 to be the first <source> been fixed yet? |
| 09:44 | <hsivonen> | I suspect that once that bug gets fixed, putting .mp4 first will continue to live on as a cargo cult practice long after |
| 09:46 | <othermaciej> | I can try it if you have a test page up |
| 09:47 | <othermaciej> | if not, then if you have a Radar number I can encourage the relevant engineers to fix it |
| 09:47 | <zcorpan> | hsivonen: http://diveintohtml5.org/video.html says it was fixed in iOS 4 |
| 09:49 | <hsivonen> | zcorpan, othermaciej: thanks. I trust diveintohtml5 |
| 09:50 | <hsivonen> | and will remove the remark about the bug from the presentation slides I intend to show tomorrow |
| 09:52 | <zcorpan> | "[whatwg] Canvas.getContext error handling" - hmm, maybe one should review webgl |
| 10:00 | <hsivonen> | volkmar_: how does Firefox decide what to suggest in input=type URL? |
| 10:18 | <jacobolus> | Hixie: you're also http://en.wikipedia.org/wiki/Special:Contributions/Hixie ? |
| 10:19 | <jacobolus> | to answer your question, yes there are parts that should have some stars |
| 10:25 | <jacobolus> | Hixie: just in general the way that the conversion is written in that color difference article is quite inelegant |
| 10:49 | <Hixie> | jacobolus: yeah. i ended up following http://www.ece.rochester.edu/~gsharma/ciede2000/ciede2000noteCRNA.pdf instead, which has some test data which is rather useful |
| 10:49 | <jacobolus> | Hixie: what are you using it for? |
| 10:49 | <jacobolus> | Hixie: I mean to do some javascript (coffeescript) implementations of these in the not-too-distant future; I have a CIECAM02 implementation in coffeescript |
| 10:51 | <jacobolus> | Hixie: to be honest, CIEDE2000 is kind of overkill for most reasonable purposes |
| 10:51 | <jacobolus> | it's the result of over-fitting a model to data |
| 10:52 | <Hixie> | jacobolus: i'm using it for an absurdly over-engineered way of making player colours distinct in a game i'm writing |
| 10:52 | <jacobolus> | ah, not such a good use |
| 10:52 | <jacobolus> | Hixie: CIEDE2000 is only accurate for very small color differences |
| 10:52 | <jacobolus> | for large ones just use the regular delta-E |
| 10:53 | <jacobolus> | that is, the 1976 version |
| 10:53 | <Hixie> | like i said, over-engineered :-) |
| 10:53 | <jacobolus> | it's just as good |
| 10:53 | <jacobolus> | yeah, but you'll get a literally worse result |
| 10:53 | <Hixie> | oh? |
| 10:53 | <Hixie> | why? |
| 10:53 | <jacobolus> | it's not just "overengineering" |
| 10:54 | <jacobolus> | because this is designed for making color tolerances for very small color differences |
| 10:54 | <jacobolus> | the CIE itself doesn't recommend using it for anything larger than delta E of a few |
| 10:54 | <jacobolus> | let me see if I can track down the threshhold they recommend |
| 10:54 | <Hixie> | all i'm using this for is determining if two colours are in the same ball park |
| 10:54 | <Hixie> | if they are, i randomise one |
| 10:55 | <jacobolus> | oh. you definitely don |
| 10:55 | <jacobolus> | 't need it for that either |
| 10:55 | <jacobolus> | just use delta E |
| 10:55 | <jacobolus> | :) |
| 10:55 | <jacobolus> | also, how big is your "ballpark"? |
| 10:55 | <Hixie> | dunno yet |
| 10:56 | <jacobolus> | CIEDE2000 is not recommended for distances bigger than DE = 5 |
| 10:56 | <Hixie> | players pick their colours, i just want to make sure that if two players who picked confusingly similar colours play each other, i pick a second colour for one of them so that tehy don't have confusingly similar colours |
| 10:56 | <wilhelm> | What's the game? (c: |
| 10:56 | <jacobolus> | Hixie: hmm. I would recommend you force the lightness to differ by some amount |
| 10:57 | <jacobolus> | so that color blind users will be able to play too |
| 10:57 | <jacobolus> | will help everyone else as well |
| 11:06 | <jacobolus> | Kuehni: "Fitting of ellipsoids in CIELAB space to experimental data demonstrates both commonalities and significant differ- ences in different data sets. The causes of these differences are generally unknown. As a result, a formula fitting a given set of data relatively closely may fit another one much less well, that is, predict its average data with more error." |
| 11:06 | <jacobolus> | "... In multiple field tests, in the textile and other indus- tries, CMC2000 has not been found to be statistically sig- nificantly better (based on simple correlation) than the widely used CMC formula and as a result the former has not been promulgated in standards in several industries." |
| 11:07 | <Hixie> | wilhelm: nothing to show yet. |
| 11:08 | <Hixie> | jacobolus: "CMC formula"? |
| 11:09 | <Hixie> | jacobolus: btw it'd be good to have this kind of thing mentioned in that article ;-) |
| 11:09 | <jacobolus> | Hixie: the CMC formula is described in that article |
| 11:10 | <Hixie> | ah, indeed |
| 11:10 | <Hixie> | i meant the comparative stuff though |
| 11:10 | <Hixie> | like, which to use when |
| 11:10 | <jacobolus> | it's a british thing |
| 11:10 | <jacobolus> | they're all mainly useful for color tolerances at small differences |
| 11:10 | <jacobolus> | like figuring out if your two cans of paint will match |
| 11:11 | <jacobolus> | none are especially useful for quantifying larger color differences |
| 11:11 | <Hixie> | so what's good for the latter? |
| 11:11 | <jacobolus> | there's too much inter-observer variability, non-uniformity, etc. |
| 11:11 | <jacobolus> | it's an unsolved (and maybe unsolvable) problem |
| 11:13 | <Hixie> | well i have this CIEDE2000 thing implemented now, might as well see if it works or not |
| 11:13 | <jacobolus> | go ahead |
| 11:13 | <jacobolus> | it'll work just as well as anything else |
| 11:13 | <jacobolus> | :) |
| 11:13 | <Hixie> | thanks for the suggestions though :-) |
| 11:15 | <jacobolus> | Hixie: I'm booked solid and firing on all cylinders on this startup job I just started a week ago, but I'll send you a link when I've got my CIECAM02 implementation actually doing something interesting |
| 11:15 | <Hixie> | cool |
| 11:35 | <Hixie> | jacobolus: yeah, you're right, this isn't much good. |
| 11:35 | <Hixie> | ok bed time |
| 11:35 | <Hixie> | nn |
| 11:36 | <jacobolus> | Hixie: my recommendation would be something like: if 2 colors are within 30° hue of each-other, enforce a 30 or 40 lightness difference |
| 11:36 | <jacobolus> | and force colors to be relatively colorful |
| 11:37 | <Hixie> | yeah, i'll see if i can come up with some good heuristic. |
| 11:37 | <Hixie> | not tonight though. :-) |
| 11:37 | <jacobolus> | how many colors do you expect to have? |
| 11:37 | <Hixie> | up to a dozen or so |
| 11:37 | <jacobolus> | Hixie: this is a pretty old thing, but kind of fun :) http://www.hcs.harvard.edu/~jrus/olpc/colorpicker.svg |
| 11:37 | <Hixie> | i'll poke around with it tomorrow |
| 11:37 | <Hixie> | gotta go now |
| 11:38 | <Hixie> | later |
| 11:38 | <Hixie> | (and thanks again) |
| 11:38 | <jacobolus> | feel free to email w/ color questions ever |
| 11:38 | <jacobolus> | or leave notes on wikipedia, or ping me on IRC, or what have you |
| 11:46 | <hsivonen> | I have a local JS app as a file: URL. I keep an event log as a JSONifiable array. What's the best way to save the log in case of browser crash? |
| 11:47 | <hsivonen> | should I write it in localStorage with a fresh key every time I append something to the log? |
| 12:53 | hsivonen | finds http://www.w3.org/TR/NOTE-xh#script-hack from 1998 |
| 13:52 | hsivonen | finds "They are dependent on XML Schema data types [XML Schema 2]." in the Ontology for Media Resource spec |
| 14:10 | <hsivonen> | "Besides that, the document presents a Semantic Web compatible implementation of the abstract ontology using RDF/OWL." |
| 14:10 | <hsivonen> | different kind of "implementation" |
| 15:17 | <zewt> | <zcorpan> "[whatwg] Canvas.getContext error handling" - hmm, maybe one should review webgl |
| 15:19 | <zewt> | there was just a mail to their list complaining that shader compiles take too long and time out--in some ways they seem to be making the mistakes of older web APIs, with long-running sync calls in the main thread with brittle timeouts ... |
| 15:26 | Philip` | wonders if shader compile times are a problem for more than just the terrible exponential-time (I think) parser in slightly old versions of Mesa |
| 15:26 | <zewt> | dunno; it does sound strange that compiling any shader would take that long, even a complex one |
| 15:27 | <zewt> | though the problem definitely exists in other places in webgl (drawing with an expensive shader) |
| 15:30 | <Philip`> | I don't see why it'd be fundamentally different to compiling JS - you want a basic roughly-linear-time compiler so it doesn't block for long, and then when you've got time you do some heavier optimisations |
| 15:31 | <Philip`> | That sounds better for authors than forcing them to write everything with async APIs |
| 15:32 | <Philip`> | (I presume it's just not something driver developers have cared about yet, since they're usually in environments where compile times don't matter or shaders are short) |
| 15:35 | <zewt> | if you compile a shader and use it immediately, you probably don't want to use a quick, unoptimized version of it because you havn't had time to optimize it yet--it could make the rendering using it catastrophically slow |
| 15:35 | <zewt> | though either way there should be async APIs for the main drawing calls (shaders can take a long time to run), and in that case the optimization could be folded into that |
| 15:45 | <zewt> | http's Content-Disposition should never have been an HTTP header, it should have been an attribute of <a> (and maybe <area>) to begin with |
| 15:45 | <zewt> | it doesn't make any sense for a resource to declare "this file is meant to be saved to disk"; that's a question for the user of the resource, not the resource itself |
| 15:48 | <kennyluck> | zewt, well, that's arguable. What if I want to send someone a downloadable URL in plaintext mail? |
| 15:49 | <Philip`> | zewt: Use a quick lightly-optimised version, and then while it's busy running on the GPU you can recompile it on the CPU, perhaps |
| 15:49 | <zewt> | that's a UA issue: browsers should make it easier to download a URL |
| 15:50 | <hsivonen> | kennyluck: normal people don't tweak server config in order to be able to email a URL |
| 15:50 | <zewt> | and many people are unable to |
| 15:51 | <zewt> | (not like I'm suggesting C-D go away, of course, but I've lost count of the number of times I've needed something like <a download> |
| 15:51 | <zewt> | ) |
| 15:52 | <zewt> | Philip`: but if all calls are blocking, then you're either spending a lot of blocking time compiling, or trading that for spending extra time rendering with a slow shader |
| 15:52 | <zewt> | lacking any async API, that is |
| 15:53 | jgraham | wonders if people really believe that facebook implementing something almost, but not quite entirely, unlike RDFa is actually an accident |
| 15:55 | <Philip`> | I think the Google Rich Snippets people implemented something not quite like RDFa and were quite clear that that was perfectly intentional and not going to change because they didn't care or think it was a problem |
| 15:57 | <jgraham> | How does their implementation differ? |
| 15:57 | <hsivonen> | jgraham: I guess it's easy to believe it's an accident if one starts with the assumption that Facebook cares about RDFa |
| 15:58 | <zewt> | gah firefox only uses JSON for History states, not structured clone |
| 15:58 | <Ms2ger> | s/facebook/anybody else/ |
| 15:58 | <Ms2ger> | zewt, I think I saw a patch for that recently |
| 15:58 | <jgraham> | But it seems to require you to bleive lots of things that obviously aren't true like "facebook developers are mostly clueless" |
| 15:58 | <zewt> | it would be nice to be able to stash File objects in there, so restoring a browser session could restore selected files in history |
| 15:58 | <jgraham> | and "facebook has no QA whatsoever" |
| 15:59 | <Philip`> | jgraham: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0124.html |
| 15:59 | <Philip`> | Apparently it was less like RDFa than I remember |
| 15:59 | <jgraham> | (well there is a little truth in the second is as far as they allegedly has a high developer / QA ratio. But nevertheless even basic QA would have caught this obvious a "bug") |
| 16:00 | <jgraham> | *have |
| 16:00 | <zewt> | (which, actually, is the only use case I've thought of for the history state object at all--everything else I generally encode into the URL) |
| 16:00 | Philip` | has no idea if it's changed since then |
| 16:00 | <Philip`> | (Also http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0126.html - "we will also deviate from the standard in some cases to be forgiving of webmaster errors. For example, we expect that some webmasters will forget the xmlns attribute entirely.") |
| 16:01 | <hsivonen> | jgraham: my guess is that Facebook doesn't care about RDFa and only wants a W3C fig leaf for their product/service-specific syntax |
| 16:18 | <zewt> | bleh; Chrome does seem to use structured clone, and Files can be stored in history and recalled, but they're broken after a session restore |
| 16:25 | <zewt> | also doesn't seem to be any way to tell when that happens: they just turn into 0-byte files with the same filename |
| 16:56 | <zewt> | trying to feature test FF's broken History.state behavior by setting a Blob in the history and seeing if it turns into an Object; but there's no BlobBuilder in FF to create a Blob to test with. hmm... |
| 16:57 | <zewt> | guess I could try using ImageData, but I'd hate to use Canvas for a FileAPI test |
| 16:57 | <Ms2ger`> | https://bugzilla.mozilla.org/show_bug.cgi?id=648997 |
| 16:58 | <zewt> | (I want BlobBuilder too, of course, but I'm stuck with what I don't have :) |
| 16:59 | <Ms2ger`> | And https://bugzilla.mozilla.org/show_bug.cgi?id=551225 |
| 17:11 | <zewt> | ick: FF doesn't support structured clone for File at all, apparently |
| 17:15 | <zewt> | which is odd--that's needed for all file access in workers |
| 17:22 | <rubys> | Gold star to philip` for http://krijnhoetmer.nl/irc-logs/whatwg/20110411#l-573; that's the type of evidence that argues for the proposal that James Graham previously outlined (and did not argue for either of the previous Change Proposals) |
| 17:23 | <rubys> | @hsivonen, your "guesses" are not likely to be sufficient to reopen this issue <http://krijnhoetmer.nl/irc-logs/whatwg/20110411#l-575>; |
| 17:28 | <erlehmann> | anyone of you coming to re:publica conference in berlin this week? |
| 17:29 | <erlehmann> | i was planning to do a panel on web standards, but after both the FSF representative and an apple-friendly web dev cannot come, i may scrap it. |
| 17:40 | <volkmar_> | hsivonen: it only shows the form history results |
| 17:47 | <TabAtkins> | I... I don't understand <http://www.w3.org/Bugs/Public/show_bug.cgi?id=12469>;. As far as I can tell, this is just a convoluted way of saying "If you let users write scripts in your page, you're screwed." |
| 17:56 | <erlehmann> | TabAtkins, the submitter should just use a spellchecker, it would have barred him from using the “document.wrtie() function“ (sic!) |
| 17:56 | <erlehmann> | :P |
| 19:29 | AryehGregor | discovers that units like em throw a monkey wrench into his algorithm, because they can't be directly compared to computed values |
| 19:31 | AryehGregor | also discovers that "specified value" already means something in CSS, so he probably shouldn't reuse it |
| 19:49 | <AryehGregor> | Maybe this is why no one allows CSS values for the fontSize command. It would be horribly confusing. |
| 19:50 | <AryehGregor> | If you allow em values or similar. |
| 20:02 | <TabAtkins> | AryehGregor: Just compute the ems as well. They compute down to px. |
| 20:03 | <TabAtkins> | (Percentages still wont' work, though.) |
| 20:03 | <TabAtkins> | (You need used values for that.) |
| 20:03 | <AryehGregor> | TabAtkins, what do you mean? |
| 20:03 | <TabAtkins> | (Which is what getComputedStyle returns, due to the terms changing after that API was created.) |
| 20:03 | <AryehGregor> | What should it mean if someone does document.execCommand("fontSize", null, "2em")? |
| 20:03 | <TabAtkins> | It should set the font-size to 2em. |
| 20:03 | <TabAtkins> | That is, twice the font-size of the parent. |
| 20:04 | <AryehGregor> | And the meaning of that from a user perspective is more or less random, right? |
| 20:04 | <AryehGregor> | Because users select visible text, not elements. |
| 20:04 | <TabAtkins> | No, it's twice as large as the surrounding text. If you select text with disparate sizes, they'll all grow twice as big. |
| 20:05 | <AryehGregor> | What if you select the element <span style="font-size: 2em">Foo</span>? |
| 20:05 | <AryehGregor> | Then the size doesn't change? |
| 20:05 | <TabAtkins> | (Well, assuming the font-size wasn't set already.) |
| 20:05 | <TabAtkins> | Yes. |
| 20:05 | <AryehGregor> | And is that supposed to be even remotely comprehensible to the user? |
| 20:05 | <TabAtkins> | At least, if you do the obvious thing from an API perspective. |
| 20:05 | <TabAtkins> | Alternately, compute 2em against the target element, then apply it. |
| 20:05 | <AryehGregor> | Because if you run the exact same command with one less letter selected, the size doubles. |
| 20:06 | <TabAtkins> | Yeah, that's a reasonabl critique. So isntead just compute 2em into px, then apply it. |
| 20:06 | <AryehGregor> | So then it just always means "double the size"? That's not what a length of 2em normally means. |
| 20:06 | <AryehGregor> | Authors who try to use em lengths for fontSize will not be expecting that at all. |
| 20:06 | <TabAtkins> | So, both options will be completely perplexing for one of your target audiences? |
| 20:07 | <AryehGregor> | Yes, so let's just not allow it. No current browser allows anything for fontSize other than 1 to 7 anyway. |
| 20:07 | <TabAtkins> | Okay. Were you just seeing if there was something comprehensible you could do? |
| 20:07 | <AryehGregor> | I was pretty sure there wasn't, is the thing, after I thought about it. |
| 20:07 | <AryehGregor> | Initially I thought "let's allow CSS sizes!" |
| 20:07 | <TabAtkins> | kk |
| 20:08 | <TabAtkins> | Note that the numbered sized are defined in terms of ems anyway, so your problem of " |
| 20:08 | <AryehGregor> | No they aren't. |
| 20:08 | <AryehGregor> | They're defined proportional to the user's font size preference. |
| 20:08 | <AryehGregor> | <font size=4> will always be the same size no matter what the parent's size is. |
| 20:09 | <AryehGregor> | That's very useful, but unfortunately CSS doesn't expose those semantics. |
| 20:09 | <TabAtkins> | Ah, okay, then it's relative to rems. |
| 20:09 | <AryehGregor> | Nope. |
| 20:09 | <AryehGregor> | rems change with the root element. |
| 20:09 | <AryehGregor> | <font size> does not. |
| 20:10 | <AryehGregor> | For document.execCommand("fontSize", null, "7") in styleWithCSS mode, WebKit outputs <span style="font-size: -webkit-xxx-large">. |
| 20:10 | <AryehGregor> | Gecko just outputs <font> regardless of mode, for fontSize. |
| 20:12 | <TabAtkins> | ...oh, huh. I never quite grasped the implications of the definition for the font-size keywords. |
| 20:13 | <AryehGregor> | Yeah, I didn't either until I just researched it yesterday. |
| 20:13 | <TabAtkins> | I wonder if that's intentional? |
| 20:13 | <AryehGregor> | It's incredibly annoying when you have things like <font size=7> not mapping to anything in CSS. |
| 20:13 | <AryehGregor> | If what's intentional? |
| 20:13 | <TabAtkins> | That it's relative to the default size, not the root size. |
| 20:14 | <AryehGregor> | I wondered whether it's intentional that rem is relative to the root size instead of default size. Being relative to default size seems considerably more useful. |
| 20:14 | <TabAtkins> | Yes, that's intentional. |
| 20:14 | <AryehGregor> | If the author specifies an absolute font-size, do UAs scale it up along with the user default preferences? |
| 20:14 | AryehGregor | tests |
| 20:14 | <AryehGregor> | Why? |
| 20:15 | <TabAtkins> | So that when you build em-based layouts, you have a unit that doesn't require adjustment if it's used within, say, a heading. |
| 20:15 | <TabAtkins> | Just set the base em size on root, and use rems everywhere. |
| 20:15 | <AryehGregor> | Yeah, but why can't you key it off the user default size instead of the root element size? |
| 20:16 | <AryehGregor> | Because you'd want to scale up the whole page for some reason? |
| 20:16 | <TabAtkins> | So the author can get an em size that they want. |
| 20:20 | <AryehGregor> | This is the kind of pain that's the reason I think <font> should remain invalid, by the way, even though <u> and similar should be valid. |
| 20:21 | <TabAtkins> | What, just that one value of <font> isn't representable in CSS? |
| 20:22 | <AryehGregor> | Plus the fact that size=1 maps to xx-small but size=2 maps to small, plus the crazy legacy parsing. And that's just for size. |
| 20:22 | <AryehGregor> | color is also terrible. |
| 20:22 | <AryehGregor> | I haven't attempted to plumb the depths of name yet. |
| 20:22 | <TabAtkins> | That way lies madness. |
| 20:22 | <TabAtkins> | font-face is horrible enough in actual CSS. |
| 20:22 | <AryehGregor> | Really? Is <font name> very different from font-face? |
| 20:23 | <TabAtkins> | I dunno how @name works - it's actually probably better, given that it's well-delineated. font-face is horrible, because it has some ridiculous specialized parsing mode. |
| 20:23 | <TabAtkins> | Such that "font-face: i am a single font name;" works. |
| 20:32 | <dglazkov> | TabAtkins: so is there an answer to how we chain selectors to the end of shadow pseudo elements? I may have missed a discussion or two |
| 20:32 | <dglazkov> | TabAtkins: for example video::-webkit-timeline:disabled |
| 20:32 | <TabAtkins> | No, there hasn't been any real activity on that. :/ |
| 20:33 | <dglazkov> | how about video:part(-webkit-timeline):disabled? |
| 20:33 | <TabAtkins> | That's the same thing (assuming you meant ::part()). |
| 20:34 | <dglazkov> | do I? :) |
| 20:34 | <TabAtkins> | Yes. video:part() is still selecting the <video>. |
| 20:34 | <dglazkov> | :( |
| 20:34 | <TabAtkins> | video::part() is selecting something else. |
| 20:34 | <dglazkov> | I thought things like nth-child select children? |
| 20:35 | <TabAtkins> | Nope. p:nth-child(1) selects the <p> if it's the first child. |
| 20:35 | dglazkov | declares himself a CSS ignoramus |
| 20:35 | <TabAtkins> | Pseudoclasses are just like classes, except they're based on information that the UA provides rather than the document itself. |
| 20:35 | <dglazkov> | so tell me how to fix this :) |
| 20:35 | <dglazkov> | now! |
| 20:35 | <TabAtkins> | Sure! It's an easy 3-step process. |
| 20:36 | <dglazkov> | nooo, not the 3-step process |
| 20:36 | <TabAtkins> | 1) Start a thread on www-style saying that you want to implement something. |
| 20:36 | <TabAtkins> | 2) ... |
| 20:36 | <TabAtkins> | 3) double rainbow |
| 20:36 | <dglazkov> | yay |
| 20:36 | <Ms2ger`> | 3) Nothing happened, goto 1 |
| 20:36 | <TabAtkins> | Nonono, *that* 3 only happens when no implementors care. |
| 20:36 | <dglazkov> | 1) throw some sh*t together in webkit |
| 20:36 | <TabAtkins> | Which is what has happened every time so far. |
| 20:36 | <dglazkov> | 2) let www-style sort it out |
| 20:37 | <dglazkov> | 3) reimplement it the right way |
| 20:37 | <TabAtkins> | I say develop a magical new way to context-switch and target a pseudo-element. |
| 20:37 | <dglazkov> | so it's really a selector |
| 20:37 | <TabAtkins> | "video %timeline:disabled" or something, so you can chain down the pseudos. |
| 20:37 | <dglazkov> | I really want it to just key off the ids |
| 20:37 | <dglazkov> | since shadow DOM subtree ids are unique to the subtree |
| 20:38 | <Ms2ger`> | TabAtkins, "we want to reserve punctuation"? :) |
| 20:38 | <dglazkov> | how about video <3timeline:disabled |
| 20:38 | <TabAtkins> | Or! Let % be a combinator. "video % timeline" means "find a <video>, then drop into the shadow subtree and find a <timeline>. |
| 20:38 | <TabAtkins> | See, I dunno what's a good idea here. |
| 20:38 | <TabAtkins> | I've got like 5 possible approaches. |
| 20:39 | <dglazkov> | I like combinators |
| 20:39 | <TabAtkins> | Combinators are good, because they keep your selectors linear. |
| 20:39 | <TabAtkins> | I like the analogy with "video > timeline" - one selects light children, the other selects shadow children. |
| 20:40 | <TabAtkins> | video ] timeline |
| 20:40 | <TabAtkins> | (Note: bad idea.) |
| 20:44 | <dglazkov> | we should use emoticons |
| 20:45 | <dglazkov> | video :) timeline |
| 20:45 | <Ms2ger`> | video :( timeline |
| 20:45 | <TabAtkins> | Let's just use pseudo-elements and let selectors extend past them. |
| 20:46 | <TabAtkins> | Wait, no, that doesn't work. >_< |
| 20:46 | <dglazkov> | TabAtkins: I am now on step 2 |
| 20:46 | <TabAtkins> | It still leaves us being inconsistent. |
| 20:46 | <dglazkov> | yeah, I already do some gnarly stuff in CSS parser to let unknown pseudo elements slide through |
| 20:47 | <TabAtkins> | In "video::timeline thumb", which is timeline a :: but "thumb" treated like a real element? |
| 20:48 | <TabAtkins> | Bah, pseudoelements are just a broken form of combinator. We can't use them. >_< |
| 20:48 | <TabAtkins> | s/which is/why does/ s/a ::/need a ::/ |
| 20:50 | <Ms2ger`> | video::shadow(timeline thumb) |
| 20:50 | <TabAtkins> | Nesting is the refuge of the weak. |
| 20:50 | <dglazkov> | why is step 2 taking so long. I sent an email to www-style like 5 minutes ago |
| 20:51 | <dglazkov> | TabAtkins: that sounds like a fortune cookie |
| 20:53 | <AryehGregor> | dglazkov, you get cooler fortune cookies than me. |
| 20:56 | <dglazkov> | dhyatt says the restrictions are silly |
| 20:56 | <TabAtkins> | Agreed that the restriction is silly, but just lifting the restriction doesn't solve the problem fully. |
| 20:56 | <dglazkov> | reply to mail then |
| 20:57 | <TabAtkins> | That's what I'm doing right now! |
| 20:57 | <dglazkov> | faster! |
| 20:57 | <dglazkov> | :P |
| 22:00 | <AryehGregor> | Yay, I just found a Firefox bug that disappears when I run it in Firebug. |
| 22:01 | AryehGregor | tries to prepare a minimal test-case |
| 22:43 | <AryehGregor> | It was one of those weird crazy bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=649138 |
| 23:01 | <jcranmer> | krijnh: ping ? |
| 23:21 | <Hixie> | TabAtkins_: hey do you know of any reason why <input type=range> wouldn't work right in chrome using xhtml? |
| 23:21 | <Hixie> | TabAtkins_: http://junkyard.damowmow.com/459 |
| 23:22 | <TabAtkins> | What's wrong with it on your machine? |
| 23:22 | <Hixie> | it's got the wrong value |
| 23:22 | <TabAtkins> | Ah, indeed. |
| 23:22 | <TabAtkins> | Nope, no idea. |
| 23:22 | <Hixie> | huh |
| 23:22 | <othermaciej> | is the bug XHTML-specific? |
| 23:22 | <Hixie> | seems that way |
| 23:22 | <othermaciej> | (also happens in Safari trunk afaict) |
| 23:23 | <Hixie> | i was just trynig to load safari trunk to test it but my webkit build seems hosed |
| 23:23 | <Hixie> | it bounces for like a minute then dies silently |
| 23:23 | <Hixie> | i'll file a bug |
| 23:23 | <othermaciej> | Web Inspector thinks it got parsed correctly |
| 23:23 | <othermaciej> | (i.e. all the attributes show up with their proper values) |
| 23:23 | <Hixie> | yeah |
| 23:30 | <Lachy> | The chances that the W3C will accept CC0 seem particularly slim, considering that they already rejected suggestions for MIT and BSD |
| 23:31 | <Hixie> | othermaciej: only seems to occur if there's a max="" as well. weird. |
| 23:32 | <othermaciej> | Hixie: the part that's mysterious to me is that it's XHTML-specific |
| 23:32 | <Hixie> | maybe something to do with the order of attributes |
| 23:32 | <Hixie> | yup |
| 23:32 | <Hixie> | changing the order changes the behaviour |
| 23:37 | <othermaciej> | attributes do indeed get processed one at a time |
| 23:37 | <othermaciej> | but I'm still puzzled that it's different between XHTML and HTML |
| 23:38 | <TabAtkins> | That's broken. |
| 23:38 | <othermaciej> | hmm, actually |
| 23:38 | <othermaciej> | I think in HTML the attributes all get assigned, and then all have their special processing done in order |
| 23:39 | <othermaciej> | in XHTML, it might be genuinely one-at-a-time |
| 23:47 | <Hixie> | filed https://bugs.webkit.org/show_bug.cgi?id=58281 |
