| 09:13 | jgraham | only just noticed that all the technical debate about EME is going to public-html-admin. Which is pretty funny. And shows that I'm a bit slow to notice things. |
| 09:29 | <sedovsek> | Hey. Is there a chance to achieve the same effect (hw accel.) in Firefox that we do with -webkit-transform: translateZ(0);? |
| 10:34 | <hsivonen> | aargh. I forgot the DOM interface for <main>. good catch by smaug |
| 10:43 | <MikeSmith> | hsivonen: your tests didn't catch that? |
| 10:43 | <hsivonen> | MikeSmith: I'm bad at writing them, apparently. this is why there should be a different QA person writing the tests |
| 12:31 | <jgraham> | hsivonen: I sort of imagine that the way that EPUB will handle compat-breaking changes is to offer multiple variations for download during transitional periods. Presumably the half-life of readers isn't going to be super-long so that seems sort of viable. I might be wrong though. |
| 12:37 | <MikeSmith> | I think what's fundamentally broken with EPUB to begin with is that I'm required to download and install something called a "Reading System" just to be able to read a book that's essentially just HTML and CSS |
| 12:38 | <Ms2ger> | But at least it's polyglot |
| 12:38 | <MikeSmith> | or actually I need to download and install multiple such Reading System applications, one for each vendor I buy books from |
| 12:39 | Ms2ger | reads dead tree books instead |
| 12:40 | <MikeSmith> | the size of my apartment I have no room for any more dead-tree books than the ones I already have |
| 12:44 | <MikeSmith> | the things I've learned from Henri have just left me thinking that there's little hope of fixing the problems with ebooks |
| 12:45 | <MikeSmith> | the current user experience around ebook reading is appallingly bad and I seems really unlikely to change much any time soon |
| 13:42 | <hsivonen> | jgraham: So you expect users to know what version of EPUB the embedded software on their device supports? |
| 13:42 | <hsivonen> | jgraham: it would be easier to rebrand the incompatible new EPUB to something other than EPUB then |
| 13:43 | <hsivonen> | jgraham: you know, unlike you and me, normal people don't load a bunch of test cases to figure out what the thing they have bought *actually* is capable of doing |
| 13:44 | <hsivonen> | (as you might infer from my emails, I have loaded some test cases) |
| 13:46 | <hsivonen> | regarding http://lists.w3.org/Archives/Public/www-style/2013Jan/0517.html : Have I misunderstood how Vary and ETag work in HTTP caching? |
| 13:47 | <hsivonen> | MikeSmith: note that there are devices with Reading Systems on them and you don’t get to download and install new ones |
| 13:47 | <hsivonen> | MikeSmith: except as part of an updated system image your vendor might be kind enough to give you |
| 13:48 | <MikeSmith> | hsivonen: yeah I was just going to say that I guess I hadn't thought about those devices enough |
| 13:48 | <MikeSmith> | and people hang on to those for a long time |
| 13:48 | <MikeSmith> | I still see a lot of older Kindles around |
| 13:49 | <hsivonen> | MikeSmith: I got one for Christmas. It has 2 EPUB engines. The Adobe one does not support EPUB3. |
| 13:49 | <hsivonen> | MikeSmith: I haven't yet proceeded far enough in my testing to be able to tell if I can load my own content into the other engine to diagnose if it supports EPUB3 |
| 13:50 | <MikeSmith> | why2 engines as atll? |
| 13:50 | <MikeSmith> | *at all? |
| 13:50 | <hsivonen> | MikeSmith: two different DRM systems |
| 13:50 | <MikeSmith> | ah yeah |
| 13:51 | <hsivonen> | MikeSmith: also, I think Kobo wants to be able to do stuff in their engine without being limited by what Adobe is willing to sell them |
| 13:51 | <hsivonen> | but AFAICT, there's no way for the user to push a standard EPUB file onto the Kobo engine |
| 13:51 | <MikeSmith> | wonderful |
| 13:51 | <hsivonen> | I suspect there is a way to push an non-standard EPUB-like file onto it, but I haven't tested that hypothesis |
| 13:52 | <hsivonen> | I'd prefer Kobo to catch up with the features of the Adobe engine before implementing some more |
| 13:53 | <hsivonen> | it really irks me that the Kobo engine doesn't do ligatures or English hyphenation |
| 13:53 | <hsivonen> | my main complaints about the Adobe engine are that it doesn't support OpenType kerning or Finnish hyphenation |
| 13:53 | <hsivonen> | also, it's too shy to hyphenate English |
| 13:53 | <hsivonen> | that is, the hyphenation threshold does not match my preferences |
| 13:54 | <MikeSmith> | better than not doing hyphenation at all I guess |
| 13:54 | <MikeSmith> | I wonder why the Kobo engine doesn't do ligatures or English hyphenation |
| 13:54 | <MikeSmith> | are both of the engines on your device based on browser engines? |
| 13:55 | <hsivonen> | I believe the Kobo thing is based on WebKit. Probably QtWebKit. |
| 13:55 | <hsivonen> | I'm pretty sure the Adobe thing is an independent impl of CSS |
| 13:55 | <MikeSmith> | ok |
| 13:55 | <hsivonen> | the Adobe folks at TPAC couldn't confirm :-( |
| 13:56 | <MikeSmith> | btw my perspective on this is biased I guess by the fact that I mostly just read books on my Android smartphone |
| 13:57 | <MikeSmith> | I used to read at lot on my iPad2 but I quit because it was a chore to carry around and actually was causing my pain in my hands because of the way you have to hold it to read |
| 13:59 | <MikeSmith> | whereas I have at least one smartphone with me all the time and holding it and using it are a lot more natural |
| 14:03 | <hsivonen> | 10" tablet for reading books: bad |
| 14:04 | <hsivonen> | smaller, lighter, less reflective screen, optional front lighting FTW |
| 14:04 | <hsivonen> | I should get around to writing a review of this thing, but I probably won't |
| 14:05 | <hsivonen> | blog posts get long. too long to be finished |
| 14:05 | <MikeSmith> | heh |
| 14:05 | <MikeSmith> | yep |
| 14:05 | <hsivonen> | I have it written in my head, but the bandwidth of braindumping is bad |
| 14:07 | <MikeSmith> | kinda like coding |
| 14:08 | <hsivonen> | totally. I also have an EPUB creation tool designed in my head |
| 14:10 | <MikeSmith> | enjoy that ability at least |
| 14:11 | <MikeSmith> | I think as you get older it gets harder to design stuff in your head |
| 14:23 | <Ms2ger> | hsivonen, does it do polyglot? |
| 14:23 | Ms2ger | runs |
| 14:24 | <hsivonen> | Ms2ger: HTML to XHTML conversion without bothering with any polyglot guarantees |
| 14:30 | <hsivonen> | so. regarding the www-style thread. I reread the relevant parts of RFC 2616 and I still think I've understood HTTP caching correctly. What I am missing or am I misunderstanding what Ilya says? |
| 14:31 | <hsivonen> | Hixie: are you paying attention to the www-style thread? It's relevant to srcset in the sense that it proposes a competing mechanism. |
| 14:31 | <Ms2ger> | I have happily ignored the thread, but maybe the IETF is missing the point |
| 14:39 | <zewt> | *insert ietf joke here* |
| 14:39 | <zewt> | (also, isn't HTTP caching an odd topic for www-style? heh) |
| 15:04 | <kamathln> | Hi, I was going through the IndexedDB specification, I tried to find what the intended behaviour is if "onversionchange" of the database object is set to null ? From firefox's behaviour, it seems it will just act like it returned success, but the specification itself does not say anything file:///home/kamathln/Documents/Indexed%20Database%20API.html#widl-IDBDatabase-onversionchange |
| 15:04 | <kamathln> | is there anything I missed? |
| 15:06 | <kamathln> | Its my first time reading specifications like this, so I wish someone could handhold me for the same |
| 15:07 | <hsivonen> | zewt: well, the HTTP-based proposal that is claimed to be cache-friendly (which I don't buy) is trying to work around the way Media Queries behave |
| 15:08 | <hsivonen> | zewt: so if MQs behaved a bit differently, perhaps we could avoid this HTTP-based workaround |
| 15:09 | <hsivonen> | zewt: not only am I skeptical about Client-Hints' cache-friendliness in general, but I'm particularly skeptical relative to MQ-based solutions if MQs are adjusted a little |
| 15:10 | <hsivonen> | cool. now there can be a showdown between the old TAG and the 4 horsemen about how much the TAG should care about closed systems |
| 15:49 | <Velmont> | Does anyone with a popular site (but not as popular as Google) |
| 15:49 | <Velmont> | actually want to rescale images on the fly (as opposed to letting |
| 15:49 | <Velmont> | Opera do it for them)? |
| 15:49 | <Velmont> | hsivonen: lol, - didn't have your own browser to use as an example? :P |
| 15:57 | <hsivonen> | Velmont: Firefox doesn’t have Turbo/Mini server-side image optimization |
| 16:01 | <Velmont> | hsivonen: Ah... It was meant like that. :-) |
| 17:01 | <dglazkov> | good morning, Whatwg! |
| 17:09 | <yroc> | dglazkov: or good afternoon or evening depending on where you are! |
| 17:18 | <zewt> | hsivonen: not familiar with the problem, but is it of the "fetching resources over and over" variety? |
| 17:19 | <zewt> | firefox is weird with subpixel widths |
| 17:20 | <zewt> | http://zewt.org/~glenn/firefox-wrapping.html chrome always sizes the box to the size of the contents; firefox makes it a pixel smaller (when the fractional part of the width is less than .5), causing the spans to be wrapped |
| 17:22 | <zewt> | i guess the span wrapping happens when the width would be greater than the truncated width, instead of the rounded width that it'll actually use |
| 17:22 | <zewt> | or ... no, but something like that |
| 17:29 | <zewt> | looks like it's one of those bugs that someone went "yeah let's just leave it" 5 years ago and left the whole world to get headaches because of their horrible bugs |
| 17:29 | <zewt> | thanks firefox |
| 17:30 | <Ms2ger> | Yw |
| 17:33 | <zewt> | awesome, someone putting "bug" in scare quotes, as if it isn't obviously a bug |
| 17:46 | <kamathln> | hi folks, please reply to my query above even if I seem offline, I internet is flaky and I keep checking the logs to know if anyone has replied anyway |
| 17:49 | <MikeSmith> | kamathln: you might consider sending that question to the public-webapps⊙wo mailing list which is the main place where the IndexedDB spec is discussed |
| 17:51 | <kamathln> | MikeSmith: thnaks |
| 17:53 | <yroc> | \quit |
| 17:56 | <MikeSmith> | Am I the only one around here who thinks it's a bad idea to hardcode path names into build files? https://bugs.webkit.org/show_bug.cgi?id=108089 |
| 18:02 | <hsivonen> | trololol: http://lists.w3.org/Archives/Public/public-html/2013Jan/0202.html |
| 18:04 | Ms2ger | wonders who got the idea there was a torch that needed carrying |
| 18:05 | <MikeSmith> | hsivonen: think about how much different things would be if similar to that Jack guy he was offering a $10 bounty for somebody to implement polyglot support in the validator |
| 18:25 | <jgraham> | hsivonen: I was sort of imagining that a backwards-incompatible change in EPUB would be handled by device detection in whatever marketplace people are using to get their books, or by listing popular devices that consume each format on Project Gutenburg |
| 18:26 | <jgraham> | Possibly that would still be a terrible UX, but not more terrible than the fact that EPUB doesn't work on kindles at all |
| 18:27 | <gsnedders> | From a consumer POV, I wonder whether it'd be better just to call it something else. |
| 18:27 | <Ms2ger> | Do consumers actually know "epub"? |
| 18:28 | <gsnedders> | (I expect backwards incompatible changes would happen the way they do elsewhere: very, very slowly) |
| 18:28 | <TabAtkins> | Depends on what services they buy from. |
| 18:28 | <TabAtkins> | If from Amazon or B&N, likely not. |
| 18:28 | <TabAtkins> | Smaller sellers often advertise and offer ePubs directly. |
| 18:28 | <gsnedders> | Google Play explicitly has "EPUB" and "PDF" downloads for eReaders. |
| 19:00 | <Hixie> | hsivonen: i will look out for it |
| 19:22 | <Hixie> | hsivonen: what subject? |
| 19:24 | <hsivonen> | Hixie: http://lists.w3.org/Archives/Public/www-style/2013Jan/0434.html |
| 19:29 | <Hixie> | i don't understand, how does this affect srcset? |
| 19:30 | <Hixie> | srcset already doesn't download pictures that aren't relevant |
| 19:34 | <Hixie> | hsivonen: on an unrelated note, do you know what they're referring to in https://www.w3.org/Bugs/Public/show_bug.cgi?id=19590 ? i can't work out how you'd get an infinite loop |
| 19:38 | <SimonSapin> | TabAtkins: I don’t understand the part about "url() tokenization rules when writing variables" |
| 19:51 | <TabAtkins> | It should probably be valid to do things like "var-special-js-thing: url("example.com" more-stuff-here);", if it's meant to be interpreted by JS. |
| 19:51 | <TabAtkins> | But that's a bad-url token. |
| 19:52 | <TabAtkins> | Hm, though, I don't keep any details of what the token is, though. |
| 19:52 | <TabAtkins> | So nevermind, I guess. |
| 19:56 | <SimonSapin> | TabAtkins: is a serializer supposed to round-trip bad-url? |
| 19:56 | <TabAtkins> | SimonSapin: Given that it'll drop the declaration or block containing it in every other circumstance, obviously not. |
| 19:58 | <SimonSapin> | TabAtkins: I’ve had requests to preserve invalid declarations such as `*width: 100px` in tinycss for a minifier |
| 19:59 | <TabAtkins> | Ah yeah, that's possible. If you just skip the grammar-checking step, it wont' drop anything. |
| 19:59 | <TabAtkins> | But still, bad-url tokens don't have contents (neither do bad-strings), so they won't roundtrip - you can't serialize them as anything. |
| 20:00 | <SimonSapin> | btw, when you say a declaration is "grammatically valid", is that for a given property? |
| 20:00 | <SimonSapin> | is `color: 4px` grammatically valid? |
| 20:01 | <TabAtkins> | Depends on what level we're talking about. Some grammar violations are caught by the parser, like "*width:100px". Most are caught by the grammar-checking step, which is property-specific. |
| 20:01 | <SimonSapin> | "If the current declaration is grammatically valid, append it to the value of the current rule." |
| 20:01 | <TabAtkins> | (There's a line in the spec when you append a valid declaration about this, and another for when you pop a rule." |
| 20:01 | <SimonSapin> | that’s a property-specific check, right? |
| 20:01 | <TabAtkins> | Yes. |
| 20:02 | <SimonSapin> | I skip that in tinycss and leave it to the caller to filter (or not) |
| 20:02 | <TabAtkins> | Yes, that's acceptable. Officially, the full "CSS parser" is the combination of tinycss and the caller's filter. |
| 20:03 | <SimonSapin> | but `*width: 100px` is not even a declaration so preserving it for minifiers is not obvious |
| 20:04 | <SimonSapin> | it might even be a non-goal in rust-cssparser if I want servo to use it eventually |
| 20:05 | <TabAtkins> | It's a non-goal in the current Syntax spec, as that declaration would be thrown away early as a syntax error (switching over to next-declaration error state). |
| 20:05 | <SimonSapin> | yes |
| 20:06 | <SimonSapin> | the spec probably doesn’t need to care about this, but a tokenizer also needs to track source line numbers if good error reporting is desired |
| 20:07 | <TabAtkins> | (Which is now present in my cssparser, thanks to a nice patch.) |
| 20:07 | <TabAtkins> | (By espadrine, iirc.) |
| 20:07 | <SimonSapin> | nice |
| 20:10 | <SimonSapin> | doesn’t reconsume() need to check for newline too? |
| 20:11 | <Mike_2> | hi everybody |
| 20:17 | <Ms2ger> | http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0165.html |
| 20:17 | <espadrine> | SimonSapin: I thought about it, but I believe the first consume() already incremented the line number, didn't it? |
| 20:18 | <SimonSapin> | espadrine: yes, but won’t it increment again for the same newline on the next call? |
| 20:18 | <SimonSapin> | let’s write a test case :) |
| 20:19 | <espadrine> | :) good habit |
| 20:19 | <SimonSapin> | I see none has touched https://github.com/tabatkins/css-parser/blob/master/tests.js after me :p |
| 20:20 | <SimonSapin> | no I’m exaggerating, Tab has a commit |
| 20:27 | <SimonSapin> | my test framework sucks |
| 20:27 | <SimonSapin> | it can’t represent token’s line/column numbers |
| 20:29 | <SimonSapin> | espadrine: how do you extract/use these location information from a parsed stylesheet? |
| 20:29 | <espadrine> | SimonSapin: I just found a case where you do need to reset the line number |
| 20:29 | <espadrine> | but it's a parse error |
| 20:29 | <espadrine> | foo {bar:"foo\nbar"} |
| 20:30 | <espadrine> | (the \n being an actual newline character) |
| 20:30 | <SimonSapin> | espadrine: but escaped newline are valid in quoted strings |
| 20:31 | <espadrine> | those don't trigger reconsume() |
| 20:31 | <espadrine> | it needs to be a parser error |
| 20:31 | <espadrine> | that's probably why I didn't think to add that case |
| 20:35 | <espadrine> | SimonSapin: I just went through all uses of reconsume() in the tokenizer, that's the only possibility where the line number can go wrong |
| 20:35 | <SimonSapin> | ok |
| 20:35 | <SimonSapin> | I gave up on the test case. I’d basically need another test framework |
| 20:36 | <espadrine> | too bad |
| 23:16 | <a-ja> | Hixie: very low-priority ping re: rendering |
| 23:28 | <Hixie> | a-ja: pong |
| 23:28 | <a-ja> | a nit |
| 23:29 | <a-ja> | the implementation status popup thing next to sections-and-headings has wrong links in it |
| 23:30 | <Hixie> | woah |
| 23:30 | <Hixie> | oh, i see |
| 23:30 | <Hixie> | it's just that sections-and-headings doesn't have one |
| 23:30 | <Hixie> | if you want one for sections-and-headings, just alt-double-click there |
| 23:30 | <Hixie> | and it'll create one |
| 23:31 | <a-ja> | ? i see links to following section |
| 23:32 | <Hixie> | how do you mean? |
| 23:34 | <a-ja> | shows link to #quotes and the edit link point to quotes, too |
| 23:35 | <Hixie> | yes, #quotes is the previous section |
| 23:35 | <Hixie> | there's always a box at the top-left, it is the box for the most recent section to have one |
| 23:36 | <a-ja> | yep...preview, not following. |
| 23:36 | <a-ja> | k |
| 23:38 | <a-ja> | h1 ~ h2 thru h5 looks better now.....though awfully damned verbose when coding for -webkit-any, -moz-any, and :matches :/ |
| 23:41 | <Hixie> | a-ja: yeah |
| 23:54 | <Hixie> | can anyone work out why http://www.hixie.ch/tests/adhoc/dom/workers/shared/001.html fails in webkit? |
| 23:54 | <Hixie> | works in opera... |
| 23:57 | <othermaciej> | if the Web Inspector is to be trusted 001.js never gets loaded |
| 23:59 | <Hixie> | gets loaded for me (safari and chrome) according to web inspector |
| 23:59 | <Hixie> | but i can't work out how to debug a worker |
| 23:59 | <Hixie> | oh maybe event.source isn't implemented in webkit... |