| 00:03 | <grom358> | I'm looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html I don't see anywhere where it enters RCDATA state |
| 00:07 | <grom358> | oh.. i think i see.. the tree builder puts it into that mode on certain elements? |
| 00:55 | <MikeSmith> | grom358: yeah |
| 00:57 | <grom358> | also i think I found an error.. section 12.2.4.1 Data state says for NULL to emit the current input character.. but the current input character will be the NULL character |
| 00:57 | <grom358> | it should be emit the REPLACEMENT CHARACTER if I'm correct |
| 00:58 | <MikeSmith> | grom358: for which state? |
| 00:59 | <grom358> | the data state, http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#data-state |
| 01:00 | <MikeSmith> | I think that's right |
| 01:00 | <MikeSmith> | you can test it in live DOM viewer to see what browsers actually do |
| 01:08 | <grom358> | well firefox and chrome seem to ignore it |
| 01:09 | <MikeSmith> | grom358: that's what would be expected if they were following the spec |
| 01:09 | <MikeSmith> | the null character never gets consumed |
| 01:09 | <MikeSmith> | it gets ignored |
| 01:09 | <grom358> | where you getting that from? |
| 01:10 | <MikeSmith> | the algorithm for the data state |
| 01:10 | <grom358> | it says emit the current input character though.. not to ignore it |
| 01:11 | <MikeSmith> | oh |
| 01:11 | <grom358> | which makes me think its a bug with the spec |
| 01:12 | <MikeSmith> | but I think the tree builder will then ignore the null, right? |
| 01:12 | <MikeSmith> | if it's in content that was tokenized from the data state |
| 01:12 | <grom358> | idk.. that part is throwing me. Everywhere else in the spec NULL is replaced with the Unicode replacement character |
| 01:13 | <grom358> | in the tokenization section I mean |
| 01:14 | <grom358> | ah I see.. section 12.2.5.4.7 says it ignores character token that is U+0000 NULL |
| 01:15 | <MikeSmith> | yeah that's the part I was thinking of I think |
| 01:15 | <MikeSmith> | anyway it's still worth raising a bug for or posting to the whatwg list about if you think it's not clear |
| 01:16 | <grom358> | yeah.. the spec is just so big and the tree construction and tokenization so closely coupled |
| 01:16 | <MikeSmith> | Hixie could always add a note to that part of the tokenizer code to clarify why it's not replaced with a U+fffd tehre |
| 01:17 | <grom358> | yeah... that would help |
| 01:18 | <grom358> | what I don't understand is why doesn't the tokenizer just handle all the NULL characters... Like I can see sometimes in the tree construction it is ignored and sometimes replaced with U+FFFD |
| 01:18 | <grom358> | but why not just always replace it with U+FFFD |
| 01:19 | <grom358> | could be done as part of the input stream preprocessor then |
| 02:31 | <grom358> | ah... http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#consume-a-character-reference . For the codepoints like 0x0001 etc.. is it meant to say return replacement character?? I don't see anything in the tree construction that replaces them |
| 09:07 | <hsivonen> | In Aldiko (based on Adobe’s SDK), I get a blank screen if I remove space between two attributes to make XHTML ill-formed |
| 09:07 | <hsivonen> | annevk: ^ |
| 09:07 | <hsivonen> | annevk: so XML is not a lie this time |
| 09:09 | <annevk> | cool cool |
| 09:09 | <hsivonen> | annevk: test files: http://hsivonen.iki.fi/test/epub-xml/ |
| 09:10 | <hsivonen> | annevk: this is most awesome. No error message or anything. Just a blank screen. |
| 09:11 | <annevk> | technology is awesome :) |
| 09:12 | <hsivonen> | I’d appreciate it if someone with an iDevice could load the two test files in iBooks and report the results here |
| 09:29 | <annevk> | can do it later |
| 11:25 | <hsivonen> | Hixie: Your response about hoping that browsers eventually "fix" the implementation of the title attribute for footnotes seems like the same kind of misplaced optimism as hoping that browsers eventually "fix" the implementation of longdesc. |
| 12:42 | <annevk> | hsivonen: both work in iBooks |
| 12:43 | <annevk> | hsivonen: that the files are identical in content makes them somewhat confusing |
| 12:53 | <annevk> | hsivonen: so yeah, I guess Apple uses the HTML parser if you use .html as extension |
| 12:53 | <annevk> | so maybe you should make another one with .xml or so |
| 12:57 | <annevk> | zcorpan: maybe you should list me as former editor or something on html5-diff |
| 12:57 | <annevk> | zcorpan: and maybe remove the Opera affiliation |
| 12:58 | <annevk> | or say "formerly" there too |
| 13:04 | <zcorpan> | annevk: fixed in the editor's draft |
| 13:05 | <annevk> | cool |
| 13:09 | <annevk> | matjas: thanks for sorting out the separators |
| 13:10 | <annevk> | matjas: now some final word on browsers with regards to IDNA2003 vs IDNA2008 vs UTS #46 and we're all set :) |
| 13:10 | <annevk> | s/on browsers/from browsers/ |
| 13:12 | <zcorpan> | annevk: i want IDNA5! |
| 13:12 | <zcorpan> | and that's final. |
| 13:12 | <annevk> | "Domain Name Standard" |
| 13:13 | <annevk> | but I fucking hope not |
| 13:13 | <Ms2ger> | Living Domain Name Standard |
| 13:13 | <annevk> | or at least not with my name on it :) |
| 13:13 | <hsivonen> | annevk: thanks. boo Apple then. |
| 13:13 | <Ms2ger> | zcorpan, IDNA120? |
| 13:14 | <zcorpan> | Ms2ger: why 120? |
| 13:14 | <Ms2ger> | 5! |
| 13:14 | <hsivonen> | annevk: the rendering engine is supposed to take the mime type from the opf manifest—not from the file name |
| 13:14 | <hsivonen> | facepalm time: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277 |
| 13:15 | <annevk> | hsivonen: where does it say it's XML in that manifest? |
| 13:15 | <Ms2ger> | 'there is no hidden="" in HTML5 that I am aware of' |
| 13:16 | <annevk> | well, it's hidden |
| 13:16 | <hsivonen> | annevk: <item id="main" href="test.html" media-type="application/xhtml+xml"/> |
| 13:16 | <Ms2ger> | annevk, nicely done, sir |
| 13:17 | <hsivonen> | annevk: I guess more testing with prefixed SVG, etc. is required to find out if iBooks uses an HTML parser or a bogo-XML parser |
| 13:17 | <annevk> | hsivonen: ooh, that's the test.opf file |
| 13:18 | <annevk> | hsivonen: in the toc.ncx file it just points to the file |
| 13:18 | <hsivonen> | annevk: the point of the <manifest> in the opf is to provide MIME types for the zip entries |
| 13:18 | <hsivonen> | annevk: the NCX is a machine-readable table of contents |
| 13:19 | <hsivonen> | annevk: the NCX format is very, very sad, as you can see |
| 13:19 | <hsivonen> | from DAISY |
| 13:19 | <annevk> | so you search for *.opf files or is it required to be named test.opf? |
| 13:19 | <annevk> | yeah, that format is ugly |
| 13:19 | <hsivonen> | annevk: no, there’s more indirection |
| 13:19 | <zcorpan> | curious how john tries to find the answer to what the spec says about hidden="" by reading about what the spec says about <noscript> |
| 13:20 | <Ms2ger> | zcorpan, sounds like the best way to approach HTML4 |
| 13:20 | <hsivonen> | annevk: META-INF/container.xml is the well-known zip entry. It points to the opf |
| 13:20 | <annevk> | zcorpan: prolly the same way the tag talks about URLs by reading HTML rather than the new document |
| 13:20 | <annevk> | hsivonen: man, shit's complicated |
| 13:20 | <annevk> | the TAG, apologies |
| 13:21 | <darobin> | the epub format is a stinking mess |
| 13:22 | <hsivonen> | NCX is like a format parody. It requires the generator to supply an incrementing integer on the nav points for order instead of just using the order of the elements in the XML tree |
| 13:22 | <annevk> | hahahaha |
| 13:23 | <darobin> | oh yeah |
| 13:23 | <hsivonen> | darobin: what stinks except NCX? |
| 13:23 | <darobin> | and it's all in the name of performance |
| 13:23 | <annevk> | cannot make that shit up |
| 13:23 | <darobin> | because, you know, jumping everywhere around a zip archive is fast |
| 13:23 | <darobin> | hsivonen: what else is there to stink? :) |
| 13:24 | <darobin> | they would have been better off using Widgets |
| 13:24 | <annevk> | hsivonen: please make a /epub/ entry on your blog |
| 13:24 | <annevk> | hsivonen: even if just bullet points |
| 13:24 | <darobin> | s/points// |
| 13:24 | <hsivonen> | well, XML Encryption, XML DigSig and the excessive indirection of META-INF/container.xml |
| 13:25 | <darobin> | oh I'd forgotten they had the XML security stack imported in there |
| 13:25 | <hsivonen> | but the <manifest>, <spine> and <guide> stuff is rather OK |
| 13:25 | <hsivonen> | for EPUB 2.0, the metadata was OKish, too |
| 13:25 | <darobin> | I reckon it should all be in the HTML |
| 13:25 | <hsivonen> | in EPUB 3.0, they made it more complicated for no apparent practical reason |
| 13:25 | <darobin> | even if it means having to perform an indexing pass on first open |
| 13:26 | <hsivonen> | I think the use of XHTML instead of HTML is not a big deal. |
| 13:26 | <hsivonen> | and their legacy UAs now need XHTML rather than HTML |
| 13:27 | <hsivonen> | If you don’t sign stuff, you can ignore DigSig as an author |
| 13:27 | <hsivonen> | and for font mangling, you can treat XML Encryption as cargo cult boilerplate |
| 13:27 | <darobin> | I've heard a few horror stories from a small shop here that does ebooks about things like readers crashing hard because the various meta files were out of sync with the content |
| 13:28 | <darobin> | less indirection would help there |
| 13:29 | <hsivonen> | I think NCX stinks the most. I think changing metadata in an incompatible way is the weirdest decision. |
| 13:32 | <zcorpan> | i replied on the bug, not sure if that was a mistake or not |
| 13:38 | <annevk> | hsivonen: looks like XML usage would fail in iBooks |
| 13:38 | <annevk> | hsivonen: e.g. if you prefix stuff |
| 13:39 | <hsivonen> | annevk: :-( |
| 13:39 | <hsivonen> | annevk: even as .xhtml? |
| 13:39 | <hsivonen> | I thought iBook even extended XHTML with namespaced stuff |
| 13:40 | <annevk> | hsivonen: dunno about that (I think that would work, but I have not tested) |
| 13:40 | <hsivonen> | *iBooks |
| 13:40 | <hsivonen> | I guess this explains why glazou enforces .xhtml naming even though opf is supposed to allow any naming you like |
| 13:58 | <matjas> | annevk: http://mathias.html5.org/tests/url/idna2003-separators/ (using `iframe) vs. http://mathias.html5.org/tests/url/idna2003-separators/a.html (using `a`) |
| 13:59 | <annevk> | fucked up |
| 14:00 | <matjas> | me or The Web? |
| 14:01 | <Kaelig> | Hi, I have a meta proposal to make (apple-mobile-web-app-title), is it possible to have a personal account to the Wiki so I can add it? |
| 14:01 | <karlcow> | matjas: choose your pain |
| 14:02 | <annevk> | matjas: the behavior |
| 14:02 | <Kaelig> | Basically I'd like to be able to edit that page: http://wiki.whatwg.org/wiki/MetaExtensions |
| 14:02 | <matjas> | i just hope my test is correct |
| 14:03 | <annevk> | Kaelig: sure thing, need a desired account name and email |
| 14:03 | <matjas> | if this is a bug, which spec does it belong to? |
| 14:03 | <annevk> | matjas: URL needs to define this I think, unless we really want distinct behavior |
| 14:04 | <matjas> | want me to file a separate issue for this then? |
| 14:04 | <annevk> | matjas: might want to raise this on the WHATWG list actually, so bz sees it :) I can take a closer look at your tests though |
| 14:05 | <annevk> | matjas: problem is a.src |
| 14:05 | <annevk> | matjas: it's a.href |
| 14:05 | <matjas> | ah duh |
| 14:13 | <Kaelig> | annevk: Cheers, account: "kaelig", email: "kaelig⊙df" |
| 14:16 | <annevk> | "A randomly generated password for Kaelig has been sent to kaelig⊙df" |
| 14:17 | <Kaelig> | Thanks annevk :) |
| 14:17 | <Kaelig> | appreciate it |
| 14:19 | <Kaelig> | I'm not sure I understand the process of proposing a meta extension |
| 14:22 | smaug____ | hates touch events |
| 14:23 | matjas | touches hate events |
| 14:23 | matjas | events hate touches |
| 14:23 | <Kaelig> | Hopefully I did it correctly :) |
| 14:28 | <zewt> | annevk: headed to work and just throwing this out there so I don't forget--does XHR guarantee that tasks queued by "make progress notifications" to fire onprogress always happen before switching to DONE, to make sure those tasks aren't run later, firing progress after load/loadend have been fired |
| 14:28 | <annevk> | zewt: yeah I think I changed that based on your comment |
| 14:29 | <annevk> | Kaelig: looks fine to me, thanks for your effort |
| 14:29 | <hsivonen> | annevk: new test files in case you are interested in poking iBooks: http://hsivonen.iki.fi/test/epub-xml/ |
| 14:29 | <hsivonen> | findings so far: ezPDF on Android uses an HTML parser always, even for .xhtml |
| 14:29 | annevk | gets his iPhone |
| 14:30 | <hsivonen> | so you have to make polyglot content if you want to support broken reading systems like that |
| 14:30 | <annevk> | so the xhtml files are new right? |
| 14:30 | <Kaelig> | Cheers annevk, plus I didn't know Anne could be a male name! |
| 14:30 | <zewt> | don't see it offhand (maybe the task ordering implies this--not sure which task queue the actual fetch happens in) |
| 14:31 | <annevk> | Kaelig: heh yeah, kind of an exclusively Dutch thing I found out :) |
| 14:31 | <zewt> | (same thing for "timeout error", etc) |
| 14:31 | <zewt> | anyway gotta go |
| 14:31 | <annevk> | hsivonen: ill-formed renders, including both circles |
| 14:31 | <hsivonen> | wow |
| 14:32 | <zewt> | reading html specs has a way of making me late for work :) |
| 14:32 | <annevk> | hsivonen: I am kinda wondering what is going on now |
| 14:32 | <hsivonen> | so they have a bogo-XML parser |
| 14:32 | <annevk> | XML5 in iBooks? |
| 14:32 | <hsivonen> | annevk: what about the line break? does it behave like single <br> or like two? |
| 14:33 | <annevk> | I saw Apple was writing a new XML parser for WebKit at some point |
| 14:33 | <annevk> | maybe that was related somehow |
| 14:33 | <annevk> | hsivonen: single |
| 14:33 | <annevk> | "Second para. SINGLE line break: |
| 14:33 | <hsivonen> | annevk: also possible that their XML parser has a bug and my way of making the file ill-formed is too subtle |
| 14:34 | <annevk> | Line after break." is how it renders |
| 14:34 | <hsivonen> | annevk: ok |
| 14:34 | <annevk> | data:text/xml,<test test=""test=""/> fails in Safari fwiw |
| 14:35 | <annevk> | ooh |
| 14:35 | <annevk> | data:text/xml,<test xmlns=""xml:lang=""/> does not |
| 14:35 | <hsivonen> | wild |
| 14:35 | <annevk> | it's the xmlns thing |
| 14:35 | <annevk> | but Safari uses libxml2 no? |
| 14:35 | <hsivonen> | so I thought |
| 14:36 | <hsivonen> | more test cases needed! |
| 14:36 | <annevk> | heh |
| 14:36 | <hsivonen> | sadly, I’m not going to write those today |
| 14:36 | <annevk> | is this just for fun btw? or are you doing something with epub? |
| 14:36 | <hsivonen> | for fun |
| 14:36 | <annevk> | kk |
| 14:36 | <hsivonen> | I got interested in epub |
| 14:36 | <hsivonen> | so I read the spec... |
| 14:37 | <hsivonen> | and then got in the asshole mode according to Pilgrims taxonomy |
| 14:40 | <annevk> | zewt: whenever the load/error event is fired progress is fired too explicitly |
| 14:45 | <karlcow> | epub is a tad depressing, not only on the ereader side, but also on the authoring side. |
| 14:45 | <karlcow> | It would be interesting to run a survey collecting the authoring practices on epub. Maybe someone at Amazon could do that. |
| 14:52 | <MikeSmith> | http://www.slideshare.net/mnot/what-http20-will-do-for-you |
| 14:52 | <MikeSmith> | HTTP 2.0 is the new HTML5 |
| 14:54 | <annevk> | still missing error handling in HTTP |
| 14:54 | <annevk> | although I guess SPDY will make it different if there's compression and stuff |
| 15:31 | <fantasai> | Hixie: I could be wrong, but I'm pretty sure the mailing list post you're linking to on http://wiki.whatwg.org/wiki/Specs_todo is not the right mailing list post. |
| 15:41 | jgraham | counts four links to mailing lists on that page |
| 16:45 | <Hixie> | hsivonen: longdesc="" is unfixable due to content corruption because most people didn't see it; with title="" the problem is the opposite: we have good content, we just aren't exposing it to quite everyone. |
| 16:49 | <Hixie> | fantasai: can you elaborate? |
| 17:03 | <fantasai> | Hixie: It says "This mailing list post has some advice on the matter." |
| 17:04 | <fantasai> | Hixie: where the matter is volunteering to edit specifications |
| 17:04 | <fantasai> | Hixie: But the post linked from there is some random commentary wrt text breaking and <wbr> |
| 17:38 | <stevefaulkner> | hixie: your statement about good content in the title attribute is demonstrably false there loads of redundant and crap content stuffed into title attributes, especially on links, some representative examples: http://www.html5accessibility.com/tests/title-usage.html |
| 17:56 | <TabAtkins> | Ah, I didn't know zcorpan left Opera. |
| 17:56 | <Wilto> | I can vouch for that. Windows 8’s Narrator reads every `title` aloud, and the vast majority of the time it’s a duplicate of the text inside the element. It’s pretty obnoxious. |
| 18:04 | <Ms2ger> | TabAtkins, what makes you think so? |
| 18:05 | <TabAtkins> | Le sigh. Reading comprehension fail. I was reading a line from annevk *directed* to zcorpan. |
| 18:08 | <Velmont> | TabAtkins: Quit messin' with me health :S |
| 18:08 | <Ms2ger> | Velmont, so I heard this odinho guy left Opera? |
| 18:08 | <Velmont> | Ms2ger :| |
| 18:09 | <Ms2ger> | Velmont, apparently he wants to work for Mozilla? |
| 18:09 | <Velmont> | Ms2ger: Hey, I was the one giving _you_ a job offer! |
| 18:09 | <Ms2ger> | Heh |
| 18:15 | <jgraham> | Wait, what? Velmont wants to work for Ms2ger? |
| 18:16 | <Velmont> | jgraham: annevk left a big open space next to my desk, I invited Ms2ger to fill it :] |
| 18:16 | <jgraham> | You're calling annevk fat now? |
| 18:16 | <Ms2ger> | Zing |
| 18:17 | <Velmont> | O_o |
| 18:18 | <Velmont> | Ms2ger: Not coming to TPAC I guess? |
| 18:18 | <Ms2ger> | Or did you call *me* fat? |
| 18:18 | <Ms2ger> | And no, no tpac for me |
| 18:19 | <jgraham> | If Ms2ger ever comes to TPAC, we will have o rename it 2PAC |
| 18:19 | <Ms2ger> | He's aliiiiiive |
| 18:20 | <Velmont> | Ms2ger: So that's who you really are! |
| 18:20 | <Ms2ger> | Uh-oh |
| 18:20 | <Ms2ger> | I confirm nor deny that |
| 18:20 | <Velmont> | Hence the psedonym |
| 18:21 | <jgraham> | That will be the year that we all get gunned down by IETF representatives in a standards body turf war |
| 18:21 | <jgraham> | Just think |
| 18:22 | <jgraham> | The last words you will hear are destined to be "we don' need no motherf-in' text/html" |
| 18:48 | <TabAtkins> | zcorpan: Apparently we (Webkit) have a quirk that allows "width: 20 px;", etc., to match WinIE. Any evidence that this is still needed? (afaik it's not in your quirksmode draft, since I didn't fold it into Syntax). |
| 18:50 | <Ms2ger> | TabAtkins, I'm pretty sure Gecko doesn't have it, and I've never heard someone complain |
| 18:51 | <TabAtkins> | Ms2ger: Cool. I'll write a removal patch, then. |
| 18:51 | <Ms2ger> | \o/ |
| 18:54 | <Velmont> | Opera doesn't either, -- in my small test, if it's correct, http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1818 |
| 18:55 | <TabAtkins> | If someone could check IE, that'd be great. We have a bunch of "hacks to match WinIE" that are way outdated. |
| 18:56 | <Velmont> | Not Iceweasel either, only the "Web" on this machine does it. :P |
| 18:56 | <TabAtkins> | (Killed one in <marquee> yesterday. ^_^) |
| 18:56 | <Velmont> | TabAtkins: I can on monday when I'm back at work :P |
| 18:56 | <TabAtkins> | Unhelpful for me right now. ^_^ |
| 18:56 | <Velmont> | I guess "Web"'s real name is Epiphany, but they prolly didn't like the name, so made it generic. |
| 18:57 | <TabAtkins> | Anyway, since FF and O don't do it, and zcorpan didn't think it was a useful enough quirk to go in his draft, I'll try to kill it. |
| 18:57 | <Velmont> | Strange that I don't have the real browsers for the engines on this random hackspace computer, - "Web" for webkit, and Iceweasel for Gecko. The Presto one is Opera though. |
| 19:45 | <Hixie> | fantasai: no idea what i was trying to link to. I looked through the list around the time of hte wiki edit, but i don't see anything relevant. Oh well. Removed it. Thanks for the heads-up. |
| 20:44 | <stevefaulkner> | hixie: never claimed it was, (re longdesc) but would be surprised if the ratio for useful info in title is greater than 20% if you call that 'balance'. UAs have voted with their almost total lack of showing tooltips on mobile/touch |
| 20:46 | <zewt> | (a useful thing, i'd say: it discourages people from designing bad UIs that are unusable without tooltips; very annoying if you're like me and turn off tooltips because they're annoying) |
| 20:49 | <Hixie> | GPHemsley: i haven't examiend the GIF spec, so i've no idea |
| 20:49 | <Hixie> | GPHemsley: i don't know how good interop is for gif or how well the spec matches reality |
| 20:49 | <Hixie> | GPHemsley: animated gifs in particular aren't specced well though |
| 20:49 | <Hixie> | stevefaulkner: given that "90% of everything is crap", 20% seems damn good :-) |
| 20:50 | <TabAtkins> | Uh, mobile doesn't show title because you don't have the ability to communicate "hover". |
| 20:50 | <zewt> | (wow, splitting a quote in Gmail caused a random paragraph I wrote elsewhere to just vanish) |
| 20:50 | <stevefaulkner> | zewt: i have no problem with it, the only thing a title attribute is good for at this point (after 19 years) is providing an accessible name for a control, it cannot be relied upon for exposing visible content to users in any browser |
| 20:51 | <GPHemsley> | Hixie: So do you suppose it would be best to just re-spec the whole thing? As it is, it seems the spec is only available in plaintext, anyway. |
| 20:51 | <zewt> | TabAtkins: heh, my phone detects touches when my finger gets close to the screen, without touching it; probably a hardware bug, but could perhaps be leveraged for "touch hovering" :) |
| 20:52 | <TabAtkins> | zewt: Yeah, phones are reactivity-based, so getting *close* can alter the current enough to be detected. |
| 20:53 | <zewt> | probably a mis-configured capacitance threshold |
| 20:53 | <Hixie> | GPHemsley: i have no opinion because i don't have enough data to form an opinion. As a general rule, i wouldn't recommend rewriting a spec unless it was absolutely necessary, though (necessary meaning "the spec doesn't match reality so interop is poor") |
| 20:55 | <GPHemsley> | Hixie: So, if I were to want to help fulfill that todo-list bullet point, what would you recommend my first steps be? |
| 20:55 | <Hixie> | GPHemsley: read the existing spec, write a test suite, see how closely the browsers match the spec |
| 20:55 | <Hixie> | GPHemsley: collect samples of real content, see how much of it works as the spec expects |
| 20:56 | <zewt> | perhaps step 0: find a single example of an animated GIF in the wild that doesn't work in every browser :) |
| 20:56 | <GPHemsley> | zewt: I was hoping Hixie might have such examples :) |
| 20:56 | <zewt> | (not saying they don't exist, but I've never seen one) |
| 20:56 | <Hixie> | GPHemsley: (e.g. i'd expect teh latter to find that the web relies on timings doing something different than the specs say) |
| 20:56 | <Hixie> | zewt: it's good to spec things even if all today's browsers do them |
| 20:57 | <Hixie> | zewt: because (a) it helps new competition to be possible and (b) it means that in 1,000 years, archeologists can write browsers for their architectures to read today's web content |
| 20:57 | <zewt> | Hixie: sure, but the answer to that question goes towards answering whether "interop is poor" |
| 20:58 | <Hixie> | certainly wouldn't hurt to do that kind of research. indeed |
| 20:59 | <GPHemsley> | zewt: There are a ton of GIFs on the Internet that go way too fast or way too slow, but I don't know where the fault lies there. |
| 21:00 | <GPHemsley> | (Presumably somebody somewhere thought it was at some point the right speed.) |
| 21:00 | <zewt> | that might be where the delay is 0 |
| 21:01 | <zewt> | which might be an underspecced point, yeah |
| 21:02 | <zewt> | another thing that may differ, though I can't think of how it might matter, is some browsers always showing the same frame for each gif anywhere it's shown (even cross-tab/window) |
| 21:02 | <zewt> | presumably due to the underlying image implementation being the same object |
| 21:03 | <TabAtkins> | Yeah, I think we might share timers sometimes? |
| 21:03 | <zewt> | think i've seen that in FF |
| 21:04 | <zewt> | i find it odd that i've actually seen people objecting to *not* showing animated favicons in tabs, heh |
| 21:05 | <zewt> | (had to jump some hoops to prevent obnoxious sites from constantly showing animations in my tabs in FF; don't recall if that was fixed or if I just have some workaround sitting in my userChrome) |
| 21:05 | <zewt> | oh yeah i hide .tab-icon-image[src$=".gif"] |
| 21:06 | <zewt> | (and others) |
| 21:06 | <Hixie> | wtf, the building i'm in feels like it's being driven down a road on a truck |
| 21:06 | <Hixie> | (doesn't feel like an earthquake, and it's been going on for far too long to be one) |
| 21:07 | <SimonSapin> | Hixie: earthquakes can last several minutes |
| 21:07 | <Hixie> | this has been going on for like 30 |
| 21:07 | <zewt> | perhaps armageddon |
| 21:07 | <Hixie> | pretty sunny for armageddon |
| 21:08 | <SimonSapin> | (ok, japan on 2011-03-11 is not the average example) |
| 21:08 | <zewt> | armageddon: surprisingly anticlimactic |
| 21:08 | <Hixie> | brb |
| 21:09 | <zewt> | are you rebooting to see if it makes the building stop shaking? |
| 21:09 | <TabAtkins> | Hixie: No earthquake. |
| 21:26 | <annevk> | once had such a thing at Opera, was some kind of cleaning equipment iirc |
| 21:27 | <annevk> | xkcd uses title="" |
| 21:29 | <zewt> | off-hand, is conformance criteria ever applied towards JS API usage, or only HTML authoring? |
| 21:29 | <annevk> | so far I only encourage stuff with JS things |
| 21:29 | <annevk> | and some stuff I don't provide a domintro for intentionally |
| 21:30 | <annevk> | but it's not really structured or planned |
| 21:30 | <zewt> | <annevk> zewt: whenever the load/error event is fired progress is fired too explicitly <- but the "make progress definitions" might have a task queued to fire progress again (the task may have been queued right before the other firing of progress) |
| 21:30 | <Hixie> | TabAtkins: yeah i think it's really just the B40 A/C |
| 21:31 | <Hixie> | zewt: as a general rule, because scripting is impossible to statically test, we rarely bother to define authoring criteria |
| 21:31 | <zewt> | eg. 1: queue task 2: "timeout error" happens and fires progress, then 3: the queued task runs |
| 21:31 | <annevk> | no that cannot happen because timeout is also queued |
| 21:32 | <annevk> | you could get a "duplicate" maybe |
| 21:32 | <annevk> | but I think that was rather unlikely with the current definitions |
| 21:32 | <zewt> | duplicates aren't a big deal |
| 21:33 | <annevk> | I don't really like how this part of XHR is defined, but I haven't really come up with a better way |
| 21:33 | <annevk> | and putting it on github has not inspired people to fix things :) |
| 21:33 | <annevk> | they just tweet about it |
| 21:34 | <annevk> | but I suppose such a thing might take a while and editing is prolly kinda daunting still |
| 21:34 | <zewt> | like it's not clear to me when the "if timeout is not 0..." conditional is actually performed |
| 21:35 | <zewt> | those look like a set of callbacks somehow handed off to Fetch, but i don't think that's the right reading |
| 21:35 | <annevk> | fetch queues tasks |
| 21:36 | <annevk> | those tasks then run past those steps |
| 21:40 | <zewt> | annevk: aren't they in different task sources? |
| 21:40 | <zewt> | fetch is in the networking task source, XHR's queue-a-task is in the XHR's own |
| 21:41 | <zewt> | hmm, might help clarity if fetch had a name for "the algorithm run by the queued tasks", which just says "uses the resource as appropriate" |
| 21:41 | <Hixie> | yeah, one day |
| 21:41 | <zewt> | (had to squint for a bit to make that connection) |
| 21:42 | <Hixie> | we'll probably do that when we redo fetch.spec.whatwg.org |
| 22:09 | <Hixie> | annevk, zewt: did you guys see my e-mail about the 'fetch' algorithm in the thread where you're responding to bz? |
| 22:10 | <zewt> | did but don't recall it, rereading |
| 22:10 | <Hixie> | actually in your case it looks like the miscommunication is about a different issue |
| 22:10 | <Hixie> | bz is talking about links that are in documents that don't have browsing contexts |
| 22:11 | <Hixie> | not about links that are associated with documents that have browsing contexts but that aren't _in_ the document |
| 22:11 | <zewt> | ah yeah i see the difference |
| 22:11 | <zewt> | so i guess in the a.click() case, it *can't* work, since it doesn't know *what* to navigate? |
| 22:17 | <zewt> | (and doesn't have anything to navigate, for that matter) |
| 22:19 | <Hixie> | well it definitely can't work |
| 22:20 | <Hixie> | as to why it doesn't... i think a.click() might actually be a special case i should consider more closely |
| 22:27 | <Hixie> | TabAtkins: don't change [hidden] to ua.css !important! |
| 22:27 | <Hixie> | TabAtkins: i have many times made it have other styles, e.g. opacity:0 with animation |
| 22:27 | <zewt> | why not? i'm tired of having to fix hidden in every page I make, heh |
| 22:28 | <zewt> | really obnoxious that <div hidden class=foo> .foo { display: inline-block; } breaks hidden |
| 22:28 | <Hixie> | if you can find a solution that doesn't prevent me from using hidden="", please be my guest :-) |
| 22:28 | <zewt> | Hixie: i'd call that something other than hidden :) |
| 22:29 | <Hixie> | why? |
| 22:29 | <zewt> | because they're very different |
| 22:29 | <Hixie> | how are they different |
| 22:29 | <zewt> | because opacity: 0 is still there and affecting layout |
| 22:29 | <Hixie> | what's layout got to do with it |
| 22:29 | <zewt> | what doesn't it :) |
| 22:29 | <Hixie> | say i have a login <section> and an app <section>, and only one is relevant at a time |
| 22:30 | <Hixie> | hidden="" is set on the other one |
| 22:30 | <Hixie> | but i want the two to cross-fade when i switch which is hidden="" |
| 22:30 | <zewt> | not familiar with <section> |
| 22:30 | <Hixie> | <div> then |
| 22:31 | <zewt> | then now you have the "hidden" one still on top, pushing the second one down the page, so now you have to change other things to move it back up |
| 22:32 | <zewt> | (btw/fwiw, you'd probably also want pointer-events: none in that case, and IIRC that isn't supported everywhere yet) |
| 22:32 | <Hixie> | nah you just make the non-hidden one have a positive z-index |
| 22:32 | <Hixie> | and various other things like pointer-events |
| 22:32 | <Hixie> | the point is just that it should be styleable |
| 22:35 | <zewt> | my point is that the current hidden is "wrong" very often, and people can use a different attribute (data-invisible, or whatever) if they want something else--neither is ideal, but currently it seems like *everyone* has to jump hoops with hidden (anyone combining @hidden with display, anyway, which I hit constantly) |
| 22:36 | <zewt> | if there was a way to say "more important than UA styles, but less important than UA !important styles" then that'd probably be ideal, but I'm guessing that's harder, heh |
| 22:36 | <zewt> | er, less important than user !important styles |
| 22:37 | <zewt> | (i don't know half enough about the details of style resolution to state that accurately) |
| 22:37 | <Hixie> | you want it to be a higher specificity at the author level |
| 22:37 | <Hixie> | rather than being at the UA level |
| 22:37 | <Hixie> | but yeah |
| 22:38 | <Hixie> | i'm all for a better solution |
| 22:38 | <Hixie> | i guess we should drop http+aes |
| 22:49 | <Hixie> | MikeSmith: i tweaked <time> |
| 22:56 | <zewt> | (FWIW, i tend to think a better solution is to just add another CSS style eg. "rendering: none" that works like display: none, giving us the "hide this element" CSS style that should never have been part of display in the first place) |
| 22:57 | <zewt> | maybe too late for that now :( |
| 23:03 | <MikeSmith> | Hixie: yeah just saw the checkin for that |
| 23:03 | <MikeSmith> | thanks |
| 23:03 | MikeSmith | updates his <time> validation patch |
| 23:37 | <zewt> | (though I suppose if it's not too late to change [hidden] to display: none !important, then it wouldn't be too late to change it to a different style, either--same effect) |
| 23:58 | <tantek> | Hixie, how did you tweak time? |
| 23:58 | <tantek> | <time> that is |