| 00:03 | <zcorpan> | miketaylr: i see like 4 requestFullScreens in webdevdata sept |
| 01:02 | <zewt> | hard to get the feeling that feedback is being taken seriously when people reply and then make spec changes without even pretending to wait for a response |
| 07:33 | <Ms2ger> | A new gcpm editor, interesting |
| 08:59 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23873 ... |
| 09:10 | <MikeSmith> | who's the new gcpm editor? |
| 09:13 | <MikeSmith> | "what if I'm implementing a browser without JavaScript and with |
| 09:13 | <MikeSmith> | some other, concurrent language?" |
| 09:14 | <zcorpan> | nice typo "... while his neighbour, also using the wife, ..." http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html |
| 09:17 | <MikeSmith> | 笑 |
| 09:20 | <SimonSapin> | Dave Cramer from Hachette will edit GCPM |
| 09:22 | <MikeSmith> | SimonSapin: interesting |
| 10:25 | <hsivonen> | I wish I have the stamina to push for a UTF-8 default for all outgoing mail in Thunderbird. |
| 10:26 | <hsivonen> | but making encodings in Firefox less bad is enough of a job |
| 10:26 | <zcorpan> | hsivonen: who is against that? |
| 10:28 | <Ms2ger> | Japan? :) |
| 10:30 | <hsivonen> | zcorpan: Japanese feature phones, concerns about the status of GB18030 in China and general Stop Energy concerns |
| 10:30 | <zcorpan> | :-( |
| 10:30 | <hsivonen> | zcorpan: I don't buy the legal concern about China as long as Thunderbird can receive GB18030, but I haven't actually read Chinese law |
| 10:31 | <zcorpan> | pretty smart feature phones to have an opinion on that, though |
| 10:31 | <hsivonen> | A look forward to UTF-8 and SHA-2-capable phones taking over in Japan. |
| 10:32 | <wilhelm_> | Give it a few more years, and the galapagos phones will disappear. Little labour is required. Just time. |
| 10:34 | <jgraham> | Are galapagos phones like galapagos island tortoises? |
| 10:34 | <jgraham> | Because, if so, we probably only have another 90 odd years to wait |
| 10:35 | <hsivonen> | fun fact, Japanese Thunderbird defaults to ISO-2022-JP (not Shift_JIS) |
| 10:36 | <Ms2ger> | Someone here has an interesting definition of "fun" :) |
| 10:39 | <hsivonen> | I wonder how much ISO-2022-JP content there is on the Web just because of email archives produced by scripts that live dangerously and pass the original bytes through to the Web. |
| 10:40 | <darobin> | I never dared touch the default encoding in Thunderbird, because email |
| 10:40 | <zcorpan> | jgraham: i get an error when starting wptserve |
| 10:40 | <zcorpan> | File "serve.py", line 137, in start_servers |
| 10:40 | <zcorpan> | sock.shutdown(socket.SHUT_RDWR) |
| 10:40 | <zcorpan> | File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 224, in meth |
| 10:40 | <zcorpan> | return getattr(self._sock,name)(*args) |
| 10:40 | <zcorpan> | socket.error: [Errno 57] Socket is not connected |
| 10:41 | <jgraham> | zcorpan: Too much meth |
| 10:41 | <jgraham> | But, interesting |
| 10:41 | <hsivonen> | darobin: I've configured Gmail to always send UTF-8 and no one has complained. |
| 10:41 | <jgraham> | I guess this is an OSX/linux difference |
| 10:41 | <darobin> | hsivonen: that's good to know, I'll perform the same experiment here |
| 10:42 | <darobin> | well, that is, whenever it is I find the right option in Thunderbird |
| 10:42 | <hsivonen> | but then I mostly send email in English and the people to whom I send email in Finnish have up-to-date MUAs apparently |
| 10:42 | <zcorpan> | jgraham: i use os x 10.8.3, if that's useful to know |
| 10:43 | <hsivonen> | darobin: mailnews.send_default_charset in about:config |
| 10:44 | <darobin> | I use French quite a lot, so if it's problematic it'll show up |
| 10:44 | <hsivonen> | darobin: dunno where the proper UI is supposed to be |
| 10:44 | <hsivonen> | if edited via about:config, be sure to use UTF-8 in upper case |
| 10:45 | <zcorpan> | @_@ |
| 10:45 | <darobin> | hsivonen: couldn't find the proper UI, did it in about:config |
| 10:45 | <darobin> | yes, did that, ta |
| 10:45 | <darobin> | there's weird shit going on there |
| 10:45 | <hsivonen> | darobin: in about:config? |
| 10:45 | <darobin> | the previous setting was ISO-8859-1 but the emails clearly defaulted to CP-1225 |
| 10:46 | <jgraham> | zcorpan: Can you try adding try: except socket.error: pass around the shutdown call? |
| 10:46 | <hsivonen> | darobin: see the pref called intl.fallbackCharsetList.ISO-8859-1 |
| 10:46 | jgraham | can't find any UI in Thunderbird either |
| 10:46 | <darobin> | hsivonen: yeah, was looking at that — so if you use ISO-8859-1 it picks that up instead? |
| 10:46 | <MikeSmith> | hsivonen: my impression is that most Japanese mail clients are still configured by default to send mail in iso-2022-JP by default |
| 10:46 | <hsivonen> | darobin: the mailnews devs couldn't face the alias reality, so they special-case ISO-8859-1 |
| 10:46 | <jgraham> | Is it actually not possible to change though the UI? |
| 10:47 | <darobin> | hsivonen: encoding + email = success! |
| 10:47 | <MikeSmith> | shift_jis was not ever used much fur e-mail i think |
| 10:48 | <hsivonen> | jgraham: which pref does "it" refer to? Pretty sure there's no UI for intl.fallbackCharsetList.ISO-8859-1 for mailnews.send_default_charset there might be UI but I don't know where |
| 10:48 | <darobin> | jgraham: admittedly that's not something you want to expose end users to too much |
| 10:49 | <hsivonen> | jgraham: Preferences: Display: Formatting: Advanced: Character Encodings |
| 10:50 | <Ms2ger> | Hmm, mailnews.send_default_charset is already user-set to UTF-8 already |
| 10:50 | darobin | would never have looked in Display for message creation |
| 10:50 | <hsivonen> | TB has so many prefs it's generally easier to find this stuff by searching the source code. |
| 10:50 | <zcorpan> | jgraham: now i get http://pastebin.com/L2fwCHy4 |
| 10:51 | <jgraham> | Yeah the "display" thing threw me |
| 10:51 | <jgraham> | I would have assumed it was under "composition" |
| 10:51 | <Ms2ger> | ^ |
| 10:51 | <darobin> | jgraham: ditto |
| 10:52 | <jgraham> | zcorpan: So that's what I got before I added the shutdown() thing |
| 10:52 | <jgraham> | I will need to investigate more |
| 10:52 | <hsivonen> | MikeSmith: yeah, I don't expect Shift_JIS to be used for email much. It's just interesting that Japanese a locale where the mail and Web legacy differs |
| 10:52 | <zcorpan> | jgraham: ok |
| 10:53 | <hsivonen> | another fun fact, the Russian localization of TB already defaults to UTF-8 for outgoing email. |
| 10:53 | <hsivonen> | (falls back to windows-1251 for unlabeled incoming) |
| 11:08 | <hsivonen> | What's taking Opera so long to get Chromium running on Linux? Or has Opera silently dropped Linux support? |
| 11:10 | <jgraham> | hsivonen: That seems like the kind of question that is inevitably "no comment" |
| 11:15 | <annevk_> | darobin: earlier, with CP-1225, did you mean windows-1252? |
| 11:16 | <darobin> | annevk_: yeah! |
| 11:16 | <jgraham> | zcorpan: BTW re: <img> <sources> and the parser-inserted flag, what about innerHTML? |
| 11:16 | annevk | also has Gmail configured to only use UTF-8 |
| 11:16 | annevk | rarely transmits anything that needs it :/ |
| 11:17 | <annevk> | Maybe I should put pile of poo in my signature |
| 11:17 | <darobin> | I don't even know what CP1225 is |
| 11:18 | <darobin> | annevk: did you have a nice weekend in HK? |
| 11:18 | <hsivonen> | darobin: a hyphen is not allowed in "cp" aliases. |
| 11:18 | <annevk> | darobin: it was most excellent |
| 11:18 | <hsivonen> | oh. the number was wrong, too |
| 11:18 | <darobin> | hsivonen: yeah :) |
| 11:18 | <zcorpan> | jgraham: good point. the proposal would make it not load for out-of-document things, which is bad. so maybe it's better to always await a stable state |
| 11:18 | <annevk> | darobin: I tried to put up a photo with the view from our apartment, but the pano feature from the iPhone has the drawback that nothing actually supports those photos it seems |
| 11:18 | <annevk> | darobin: I guess I need to host it myself |
| 11:19 | <darobin> | annevk: are you sure that it's not just that you were so drunk that the pano doesn't look like anything? |
| 11:19 | <darobin> | and the hosting sites just go "go home annevk, you're drunk" |
| 11:19 | <zcorpan> | jgraham: or the parser could avoid setting the flag in the fragment case |
| 11:20 | <annevk> | darobin: that'd be an amazing feature |
| 11:20 | <annevk> | darobin: I'd love for Messages to support that |
| 11:20 | <jgraham> | zcorpan: Yeah, if it knows that it's parsing a fragment other than implicitly |
| 11:20 | <darobin> | annevk: I'm pretty sure that there are lighting and blur features you can detect |
| 11:20 | <jgraham> | I don't know that that is a requirement at the moment (it could become one of course) |
| 11:21 | <zcorpan> | jgraham: what do you mean? |
| 11:22 | <jgraham> | zcorpan: I mean I don't know if there is a need for a flag on the parser indicating that it's parsing a fragment at the moment |
| 11:22 | <zcorpan> | jgraham: first match of 'fragment case' gives "Loop: If node is the first node in the stack of open elements, then set last to true, and, if the parser was originally created as part of the HTML fragment parsing algorithm (fragment case) set node to the context element." |
| 11:24 | <jgraham> | zcorpan: Yeah, I just reached the same conclusion. So I guess that seems OK |
| 11:25 | <zcorpan> | jgraham: can you reply to the email? |
| 11:26 | <jgraham> | Sure |
| 11:26 | <zcorpan> | thx |
| 11:36 | <hsivonen> | The Polyglot guide should migrate to RFC 6919 key words. |
| 11:36 | <darobin> | heh |
| 11:39 | <zcorpan> | another thing i got thinking about is > 1 <img>s in a <picture>. the proposal would result in both images independently doing a resource selection for the same <picture>. i think that's OK but it would be easy enough to add a check that the <img> is the first <img> if we want to have it a bit more sane model |
| 11:53 | <annevk> | Polyglot is still a thing? |
| 11:54 | <jgraham> | Well yeah, but so is paganism |
| 11:54 | <jgraham> | It doesn't really affect most people's lives |
| 11:58 | <yoav> | zcorpan: A single <img> per picture is probably better, unless someone can come up with a use-case for having multiples |
| 11:59 | <zcorpan> | yoav: oh it should be invalid for authors, sure. i'm pondering what the behavior should be |
| 12:00 | <yoav> | zcorpan: having just the first one be active sounds reasonable to me |
| 12:02 | <zcorpan> | yoav: yeah, i agree. though it involves more checks (the selection algorithm needs to check that the img is the first one, inserting an img needs to rerun selection on the next img, removing img needs to run selection on the new first img) |
| 12:05 | darobin | discovers that China is one of the countries in which his operator's data roaming is not cheap — oops |
| 12:05 | <yoav> | inserting an img would probably require to re-run selection anyways (unless I'm missing something). during selection it'd walk the parent's children until it reaches itself, and if it saw an <img> on the way, selection is aborted. ( |
| 12:05 | <yoav> | (slightly hand-wavy. I'm new here) |
| 12:06 | <zcorpan> | i mean for the old-first-that's-no-longer-the-first img element |
| 12:06 | <yoav> | Oh, OK |
| 12:07 | <yoav> | Yeah, it'd needto be "turned off" |
| 12:07 | <zcorpan> | yep |
| 12:07 | <jgraham> | Isn't it easier just to make each img independent? |
| 12:10 | <zcorpan> | yes, it's easier, at least in the spec. but it seems pretty weird |
| 12:11 | <jgraham> | I don't think it's all that weird |
| 12:11 | <jgraham> | I think it's more weird to add non-obvious special cases |
| 12:16 | <zcorpan> | maybe so, i'm fine with either behavior |
| 12:16 | <annevk> | zcorpan: hey, do you know why SharedWorker makes an exception for data URLs, but does not allow e.g. blob URLs? |
| 12:18 | <zcorpan> | annevk: people asked for data: to be supported but nobody asked for blob: maybe? |
| 12:19 | <annevk> | Ugh. We really need to move to one policy across all contexts. |
| 12:24 | <hsivonen> | speaking of data: URLs, it's sad that they participate in locale-specific charset fallback |
| 12:29 | <zcorpan> | hsivonen: they do? how? |
| 12:31 | <zcorpan> | i thought data: always had a charset declared (default being 'us-ascii' label) |
| 12:33 | <hsivonen> | zcorpan: oh ok. good if so |
| 12:33 | <zcorpan> | seems so in blink but not in gecko? data:text/html,<meta charset=utf-8>å |
| 12:34 | <hsivonen> | in other news, someone with the nick "SickMind" asks how to get videos embedded in PDF to play: http://stackoverflow.com/questions/20085002/open-pdf-interactive-files-and-play-videos-integrated-in-pdf |
| 12:37 | <Ms2ger> | So, why don't my gifs animate when I print them? |
| 13:05 | <zcorpan> | it does, but the refresh rate is very slow |
| 13:09 | SteveF | suggest a change in email subject from Re: [whatwg] The src-N proposal |
| 13:11 | <zcorpan> | SteveF: what should we call the new proposal? |
| 13:13 | <SteveF> | zcorpan: new <picture> ??, don't know but it appears that the discussion has moved on from the subject |
| 13:34 | <hsivonen> | oh well. I replied to the JSON BOM thread. |
| 13:40 | <annevk> | hsivonen: I like how you made it a UTF-8 test at the same time |
| 13:42 | <annevk> | http://knowyourmeme.com/memes/%E0%B2%A0_%E0%B2%A0-look-of-disapproval :-) |
| 13:47 | <hsivonen> | UTF-8-incapable MUAs get an extra-disapproving look |
| 14:08 | hsivonen | finds out there exists something called XMLVM: http://xmlvm.org/overview/ |
| 14:25 | <yoav> | SteveF: I say picture 2.0 :P But seriously, it's not just picture (even though I agree it's not src-N either) |
| 14:30 | <zcorpan> | maybe Lazarus-picture (https://twitter.com/stevefaulkner/status/402930161479217152 ) |
| 14:33 | <newtron> | zcorpan: what are your thoughts on non-img children of nu-picture, for accessibility/fallback? |
| 14:33 | <newtron> | sorry, Lazarus-picture |
| 14:33 | <newtron> | :) |
| 14:34 | <newtron> | would there be a way to visually hide any non-img children, but assign them the equivalent of an alt-text role? |
| 14:34 | <yoav> | "New picture - an element so nice, they named it twice" |
| 14:34 | <zcorpan> | newtron: i think we should stick to alt="" |
| 14:35 | <newtron> | zcorpan: i think that might be a missed opportunity. one of the things authors loved about <picture> was the ability to do more advanced accessible fallbacks |
| 14:35 | <newtron> | like tables, etc |
| 14:35 | <yoav> | SteveF: Thoughts on the accessibility stuff? |
| 14:36 | <newtron> | zcorpan: authors are also used to the <video><source /><p>fallback</p></video> pattern |
| 14:37 | <zcorpan> | newtron: i haven't seen a proposal on how rich fallback would actually work |
| 14:37 | <SteveF> | yoav: to be honest will need to look into again before I can make nay worthwhile comment, will await an emergent draft proposal |
| 14:37 | <zcorpan> | newtron: note that <video> doesn't have fallback for accessibility purposes |
| 14:37 | <jgraham> | Hmm, so zcorpan is Jesus? Might still turn out that he is Orpheus and this is Eurydice-<picture> |
| 14:38 | <newtron> | zcorpan: well, they have <video><source /><track /></video> |
| 14:38 | <SteveF> | zcorpan: would be nice if it was like canvas for rich text as in represented in acc tree, but don't know how practical that is |
| 14:40 | <yoav> | newtron: I wouldn't significantly complicate the algorithm in order for that to work, since it's not the reason we're doing this, but it would certainly be a nice to have. I say let's wait for SteveF's analysis |
| 14:41 | <newtron> | yoav: i agree, it's not worth a lot of complication now, since we have alt and longdesc still |
| 14:41 | <newtron> | but if it's easy, it's a nice win |
| 14:42 | <zcorpan> | i think enabling rich fallback for images is a separate thing that can be done for <img> separately if people are actually interested in implementing that in browsers and ATs |
| 14:43 | <zcorpan> | so far i haven't seen any actions in that direction, and rich fallback for images is already possible in html with <object> but nobody is using it and i don't know what the support is in ATs |
| 14:43 | <yoav> | zcorpan: Perhaps just make sure the algorithm ignores anything that's not <source>, so it can be added on later |
| 14:44 | <yoav> | Or anything after the <img> itself |
| 14:44 | <newtron> | yoav: ignores + hides, or ignores + renders? |
| 14:45 | <zcorpan> | yoav: yeah it would go through the children and look at <source> and the <img> itself (and stop when it reaches itself) |
| 14:46 | <zcorpan> | newtron: the proposal is to have <picture> be a normal inline, so stuff inside it renders |
| 14:46 | <zcorpan> | but only <source>+<img> would be allowed for now |
| 14:46 | <newtron> | ok. that sounds decent. |
| 14:46 | <newtron> | so if somebody threw something else in there (against the spec), it would get rendered and they could visually hide it if they wanted with css. |
| 14:46 | <zcorpan> | sure |
| 14:46 | <newtron> | but still leave it available to AT |
| 14:47 | <newtron> | nice |
| 14:47 | <zcorpan> | it wouldn't be any different to <img><span>stuff</span> today |
| 14:49 | <newtron> | if it would work like that, could the spec explicitly allow for it, even if it's ignored? it seems like a pretty nice way to handle the issue |
| 14:49 | <zcorpan> | does anyone know what the landscape is like for <object> fallback in ATs? |
| 14:50 | <zcorpan> | newtron: if you want to do hacks you might as well put the fallback outside the <picture>, it would mean the same thing |
| 14:52 | <newtron> | zcorpan: maybe, but i'm suggesting that it's not a hack, it's a feature. you also get a styling hook because it's a child of picture. |
| 14:52 | <zcorpan> | newtron: ok, then, i don't follow what you are suggesting |
| 14:52 | <newtron> | just that the spec ignore, but not explicitly forbid, any non-img children of picture |
| 14:53 | <zcorpan> | what do you mean by ignore? |
| 14:53 | <newtron> | not used in the selection algo in any way |
| 14:53 | <zcorpan> | so that's the case in the proposal already. but i don't see how that helps you with making fallback actually work |
| 14:54 | <newtron> | sorry, then i misunderstood. you said "only <source>+<img> would be allowed for now". i'm just saying that shouldn't be an explicit limitation in the spec |
| 14:55 | <zcorpan> | why? |
| 14:56 | <newtron> | so that if authors do it, it doesn't end up getting flagged as wrong, in say a validator |
| 14:56 | <newtron> | anyway, i think it's not necessarily soemthing that needs to get worked out now |
| 14:57 | <newtron> | i'm happy to put this on hold until the dust settles on this more |
| 14:57 | <newtron> | i was just curious about how it would work with the current proposal |
| 14:57 | <SteveF> | zcorpan: the limitation of <img> has always been that the short text alternative can only be a string, what is alluring is the opportunity to add markup to it |
| 14:57 | <zcorpan> | what i'm missing is the proposal about how the fallback mechanism would work |
| 14:59 | <zcorpan> | yeah i understand that it is a limitation. but there is a solution already (<object>) and it's not used and not supported (or is it?) |
| 14:59 | <zcorpan> | if people don't use or support rich fallback for <object>, what reason do we have to believe that they would do for <picture>? |
| 15:00 | <hsivonen> | looking forward to seeing if the case where the user overrides a previous override from the charset menu go down after the new charset menu hits the release channel |
| 15:00 | <zcorpan> | hsivonen: what's new? |
| 15:00 | <hsivonen> | zcorpan: https://bugzilla.mozilla.org/show_bug.cgi?id=805374 |
| 15:01 | <hsivonen> | zcorpan: oh as in what's different? |
| 15:01 | <hsivonen> | zcorpan: fewer encodings. Windows encodings offered before ISO encodings |
| 15:01 | <zcorpan> | hsivonen: yeah. ok |
| 15:02 | <newtron> | zcorpan: you mean like <object data="img.png"><!-- fallback --></object>? |
| 15:03 | <hsivonen> | zcorpan: all encodings that are available are in one list, so no guessing where Turkish, Thai and Vietnamese fall in the taxonomy "East Asian", "SE & SW Asian", "Middle Eastern" |
| 15:03 | <zcorpan> | newtron: yes |
| 15:03 | <newtron> | zcorpan: i can't speak to how well that works with AT, but it can cause problems for just the img |
| 15:03 | <hsivonen> | zcorpan: or guessing that Greek is West but Polish is East |
| 15:03 | <newtron> | e.g. not being able to right-click save, etc |
| 15:03 | <newtron> | which i think has discouraged authors |
| 15:03 | <zcorpan> | hsivonen: ok, sounds like an improvement |
| 15:05 | <SteveF> | zcorpan: can't recall object for image support, but here are results of recent test using object for svg https://dl.dropboxusercontent.com/u/377471/SVG/adobesvgtest6.html and they ain't pretty |
| 15:06 | <zcorpan> | SteveF: thanks. that doesn't test <object>'s fallback it seems |
| 15:06 | <hsivonen> | zcorpan: also, no more baiting people with Mac encodings or ISO-8859-n where n > 11 |
| 15:07 | <zcorpan> | newtron: yeah, so it seems like a good move to avoid that situation for <picture> :-) |
| 15:07 | <SteveF> | zcorpan: no, right my thoughts on <picture> are not the classic 'fallback' |
| 15:08 | <SteveF> | zcorpan: but for when <picture> is supported being able to access content in the sub tree |
| 15:08 | <zcorpan> | SteveF: i don't follow |
| 15:09 | <newtron> | zcorpan: i don't follow that argument. people don't use object for images because object is bad at displaying images. that doesn't mean <picture> shouldn't be able to have fallback content |
| 15:10 | <zcorpan> | newtron: i mean it avoids the problem with the different context menu |
| 15:10 | <newtron> | zcorpan: oh. then yes. :) |
| 15:10 | <SteveF> | zcorpan: like <canvas> now http://www.html5accessibility.com/tests/canvas.html |
| 15:12 | <zcorpan> | SteveF: oh, do you mean that the fallback should be able to receive keyboard focus? |
| 15:14 | <SteveF> | not suggesting that interaction be exposed as in canvas, but that a text alternative be exposed such as <picture><p> <span lang="es"hola</span> is spanish for hello</p></picture> |
| 15:15 | <SteveF> | not a good example but get my drift |
| 15:16 | <zcorpan> | i don't, sorry :-) |
| 15:17 | <SteveF> | zcorpan: currently <img alt="hola is spanish for hello"> cannot convey paragraph or language |
| 15:18 | <SteveF> | with rich text alternative you could |
| 15:18 | <zcorpan> | yes i understand the difference between alt="" and HTML content |
| 15:19 | <SteveF> | so what is it you don't understand? |
| 15:19 | <zcorpan> | what i don't understand is how the mechanism would work for <picture> |
| 15:20 | <SteveF> | if content subtree elements exposed in acc tree then they can be accessed by AT |
| 15:20 | <SteveF> | as they are in canvas |
| 15:21 | <zcorpan> | right, for the <picture> proposal that's the case as if the <picture> was a <span> |
| 15:22 | <jgraham> | Do you need more than picture > * {display:none} picture > img {display:inline} ? |
| 15:22 | <zcorpan> | let's discuss a concrete example. <picture> <source ...> <img alt="alt" ...> Hello </picture> |
| 15:23 | <zcorpan> | jgraham: that wouldn't hide text and it wouldn't show the fallback when the image isn't shown |
| 15:23 | <jgraham> | zcorpan: Fair enough |
| 15:23 | <zcorpan> | when the image is shown, what happens? |
| 15:23 | <zcorpan> | when the image isn't shown, what happens? |
| 15:23 | <zcorpan> | and how? |
| 15:24 | <zcorpan> | what if there are two <img>s in there? |
| 15:25 | <SteveF> | zcorpan: i would suggest that if img's disabled not available then both alt and text be displayed |
| 15:26 | <zcorpan> | SteveF: how? |
| 15:27 | <SteveF> | zcorpan: how is alt text displayed in that case now? |
| 15:28 | <SteveF> | zcorpan: anyway not saying i have any answers just blowing smoke out of my a11y pipe, gotta go do some paid work now, will follow along |
| 15:29 | <zcorpan> | SteveF: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#images-0 |
| 15:30 | <SteveF> | so how will that translate to <picture> for alt? |
| 15:31 | <zcorpan> | in my proposal it is unchanged |
| 15:34 | <SteveF> | zcorpan: ok as i said need to work and to look at proposal more |
| 15:34 | <zcorpan> | ok |
| 15:35 | <newtron> | zcorpan SteveF: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element the two paragraphs starting with "In non-visual media..." (although the interactive bits don't apply) |
| 15:35 | <newtron> | seems like that would be what is appropriate for picture too |
| 15:36 | <newtron> | so in jgraham's scenario -- if the image is shown, the fallback content is not (though is still there in the accessibility tree) |
| 15:36 | <newtron> | if the image is not shown, the fallback content is |
| 15:37 | <newtron> | in addition that, the alt text would be shown as it is now for img |
| 15:39 | <zcorpan> | newtron: but the fallback content are siblings to <img> |
| 15:40 | <newtron> | zcorpan: yes |
| 15:41 | <zcorpan> | so how do you hide the fallback content? |
| 15:41 | <newtron> | not sure. how is content fallback hidden? |
| 15:41 | <newtron> | *canvas |
| 15:42 | <zcorpan> | by making the canvas element a replaced element, and the fallback content are children |
| 15:42 | <newtron> | hmm |
| 15:45 | <newtron> | yup, that's a tough problem |
| 15:45 | <newtron> | i don't have an answer |
| 15:47 | <newtron> | my personal take is that I don't mind hiding the fallback content with CSS, as long as it's there in the AX tree. which means no change to the current proposal, other than explicitly allowing said fallback content. |
| 15:50 | <zcorpan> | newtron: so that wouldn't make the fallback available when the image isn't shown, other than for AT users |
| 15:51 | <zcorpan> | that seems like a worse situation than alt="" |
| 15:51 | <newtron> | zcorpan: you mean in the case where images are allowed, but it fails to load for whatever reason? |
| 15:51 | <zcorpan> | yeah |
| 15:51 | <zcorpan> | or the user has disabled images |
| 15:51 | <newtron> | in the first case, i'd hope/assume that was rare enough that the alt text should be fine |
| 15:52 | <newtron> | in the second i'm less comfortable with it |
| 15:52 | <newtron> | but it might be an ok compromise |
| 15:53 | <newtron> | zcorpan: i would always set alt in addition to any other fallback content |
| 15:54 | <Domenic_> | annevk: yesss fixing the file:/// URLs on Windows. |
| 15:54 | <annevk> | Domenic_: hah, turns out it's way complicated |
| 15:54 | <zcorpan> | i think it seems like a hack that works for some users but doesn't work for other users, and doesn't need the spec's blessing in order to be used (you can put the fallback as a sibling to <picture>) |
| 15:54 | <annevk> | Domenic_: see that Chrome bug for other examples of file URLs |
| 15:54 | <annevk> | Domenic_: file URLs are fucked |
| 15:54 | <annevk> | Domenic_: especially brettw's last comment on that bug |
| 15:54 | <newtron> | zcorpan: you're right, this is sounding hacky |
| 15:55 | <newtron> | the canvas thing is, imo, the nicest solution, but i have no idea if/how it's implementable |
| 15:56 | <zcorpan> | newtron: i'm not really against rich fallback for images, i think it would be good to have it, but i haven't seen a concrete proposal yet for how it would actually work. if we really want rich fallback for images, we should do it properly, imho |
| 15:57 | <newtron> | zcorpan: fair enough. my takeaway is that the way the proposal is now allows for a lot of flexibility down the road for implementing something like this, so it's absolutely not urgent to try to wedge something in now, without it being fully baked. |
| 15:57 | <newtron> | zcorpan: i appreciate your thoughts on it, thanks |
| 15:57 | <zcorpan> | newtron: np, and thank you |
| 16:10 | <annevk> | hsivonen: "Character Encoding" being a featured widget under customize Firefox is somewhat baffling |
| 16:13 | <hsivonen> | annevk: well, the assumptions are that 1) Firefox should be operable without the menubar and 2) there exist a set of users who need the feature |
| 16:15 | <annevk> | so we have this feature for the 1‰? |
| 16:15 | <annevk> | ‰ does not come out that readable compared to % :/ |
| 16:16 | <SimonSapin> | hsivonen: can’t we keep these assumptions but still make it more buried? |
| 16:16 | <hsivonen> | annevk: yeah |
| 16:16 | <hsivonen> | SimonSapin: the assumption is that the more it is buried, the worse a support issue it is in Japan |
| 16:17 | <hsivonen> | SimonSapin: how would you bury the Australis widget more? |
| 16:17 | <annevk> | I guess the whole customize button is already the 1% |
| 16:17 | <annevk> | Hopefully they do some tracking on how this is actually used |
| 16:17 | <annevk> | I just used it to remove bookmarks and the search bar, we'll see how it goes I suppose |
| 16:17 | <hsivonen> | SimonSapin: for now, I'd rather fight against adding this stuff to B2G than fight for complete removal from desktop |
| 16:17 | <SimonSapin> | hsivonen: maybe have "Character Encoding" not appear in the Australis widgets unless a preference is checked? |
| 16:18 | <hsivonen> | annevk: "they" is me for the charset menu |
| 16:18 | <annevk> | hsivonen: yeah, I meant for Australis in general, understood that we're pretty active on the charset stuff :-) |
| 16:18 | <hsivonen> | SimonSapin: at that point, we might as well not have it. that would be a user-hostile way to have it |
| 16:19 | <SimonSapin> | hum, ok |
| 16:59 | <TabAtkins> | Augh blogs with 12px font asl;dfja;sldfkj |
| 17:08 | <annevk> | § |
| 17:32 | <annevk> | Hmm, http://code.google.com/p/chromium/issues/detail?id=257354 |
| 17:32 | <annevk> | So maybe file URLs end up in "there be dragons" territory along with CSS tables |
| 17:34 | <smaug____> | dglazkov: ping |
| 17:36 | <SimonSapin> | annevk: and there there is filesystem encodings… |
| 17:36 | <Domenic_> | annevk: uncool, i think you are more right than brettw. you should get other implementers in on the discussion? |
| 17:37 | <SimonSapin> | and then* |
| 17:37 | <annevk> | SimonSapin: not sure how those are relevant to parsing |
| 17:37 | <Domenic_> | annevk: the only other sane alternative is to have a "is on windows" global flag that dictates the behavior of file URL parsing. |
| 17:37 | <SimonSapin> | annevk: doesn’t parsing have to pick an encoding when percent-encoding? |
| 17:38 | <smaug____> | or is Hayato Ito ever here? |
| 17:38 | <dglazkov> | good morning, Whatwg! |
| 17:38 | <dglazkov> | smaug____: pong |
| 17:38 | <smaug____> | there, dglazkov ! |
| 17:38 | <dglazkov> | good morning, Blink! |
| 17:38 | <smaug____> | dglazkov: good evening |
| 17:39 | <smaug____> | dglazkov: trying to understand shadow dom's event dispatch |
| 17:39 | <dglazkov> | smaug____: awesome |
| 17:39 | <smaug____> | filed few obvious bugs , but still just trying to understand what the event path looks like |
| 17:40 | <dglazkov> | smaug____: you really need hayato. I paged shadow DOM out of my head mostly. I'll try to help, but I am rusty :) |
| 17:40 | <annevk> | SimonSapin: yes, but it doesn't come from the filesystem |
| 17:40 | <annevk> | http://doctorbeet.blogspot.ru/2013/11/lg-smart-tvs-logging-usb-filenames-and.html o_O |
| 17:42 | <smaug____> | dglazkov: so as an example, http://w3c.github.io/webcomponents/spec/shadow/#distribution-results , the right most picture. If I read the spec correctly, when event is dispatched to child1, the path would be child1, insertion point 1, insertion point 3, the parent of insertion point 3, the 2nd shadow host, 1st shadow host, document |
| 17:42 | <smaug____> | and that feels odd |
| 17:42 | <smaug____> | the propagation to several insertion points, but not necessarily their parents |
| 17:42 | <smaug____> | (I could very well miss something here) |
| 17:44 | <smaug____> | but each insertion point in destination insertion points will be added to the path, and only the parent of the last insertion point will be there too |
| 17:44 | <smaug____> | dglazkov: is my interpretation correct? |
| 17:44 | <smaug____> | dglazkov: or in which timezone hayato is ? |
| 17:45 | <dglazkov> | smaug____: Tokyo |
| 17:46 | <smaug____> | and he tends to work during normal office hours ? |
| 17:46 | <dglazkov> | smaug____: yep |
| 17:46 | <smaug____> | dglazkov: is he ever on this channel or in #blink? |
| 17:46 | <dglazkov> | smaug____: let me see if I can summon him now from #blink |
| 17:47 | <smaug____> | (it is just that if my interpretation is correct, the event path is really odd) |
| 17:47 | <annevk> | it's 2:47AM in Tokyo... |
| 17:47 | <smaug____> | maybe I'm missing how insertion points work |
| 17:47 | <annevk> | smaug____: FWIW, I commented on the special casing of event types long ago |
| 17:47 | <annevk> | smaug____: and proposed an alternative |
| 17:48 | <annevk> | smaug____: not entirely sure what happened to that |
| 17:48 | <smaug____> | annevk: I thought it was filed, in some form |
| 17:48 | <smaug____> | but didn't spend time trying to find the original bug |
| 17:48 | <annevk> | smaug____: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20247#c10 |
| 17:48 | <dglazkov> | annevk, smaug____: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20247 I think it's this |
| 17:48 | <smaug____> | dglazkov: insertion points stay in the tree where they are defined |
| 17:48 | <dglazkov> | yay |
| 17:49 | <smaug____> | dglazkov: like, insertion points aren't moved anywhere? |
| 17:50 | <smaug____> | "Non-bubbling events will naturally not propagate outside shadowRoot". Er what |
| 17:50 | <smaug____> | non-bubbling has nothing to do with event propagation |
| 17:51 | <dglazkov> | smaug____: to answer your first question, the event path simply follows the structure of the composed tree |
| 17:51 | <dglazkov> | smaug____: with roots and insertion points included |
| 17:51 | <smaug____> | dglazkov: but per spec all the insertion points are in the path |
| 17:51 | <annevk> | smaug____: yeah, I recommend ignoring that comment |
| 17:51 | <smaug____> | but only the parent of the final insertion point |
| 17:52 | <smaug____> | er, final destination |
| 17:52 | <dglazkov> | smaug____: sure, because the composed tree only has that parent in it. |
| 17:53 | <dglazkov> | smaug____: I see hayato even added a nice note: "For convenience, an event path may include shadow roots or insertion points so that event listeners registered on the shadow roots or the insertion points would be invoked." |
| 17:53 | <smaug____> | the composed tree in that example certainly has the parent of all the insertion points |
| 17:55 | <dglazkov> | smaug____: but if you look at the compose tree, the path from child1 to document is: child1 -> parent of insertion point 3 -> shadow host -> shadow host -> document |
| 17:56 | <smaug____> | yes |
| 17:56 | <smaug____> | so why are we adding insertion point 1 to the event path? |
| 17:56 | <smaug____> | but not insertion point 1's parent |
| 17:56 | <smaug____> | that makes event handling rather odd |
| 17:57 | <smaug____> | usually if you handle event in nodeA, you can handle the event also in A's parent |
| 17:57 | <smaug____> | the setup feels overly complicated |
| 17:57 | <dglazkov> | because then you'll have an event tree, not event path, and I don't know how that would work |
| 17:57 | <smaug____> | do we need to have insertion point 1 in the path? |
| 17:58 | <dglazkov> | I think so -- if you're inside that shadow tree, how would you listen to an event dispatched to an element distributed into insertion point 1? |
| 17:59 | <smaug____> | now one is forced to add listeners to the insertion point |
| 17:59 | <smaug____> | and not to its parent |
| 17:59 | <smaug____> | which is totally different to normal DOM |
| 17:59 | <dglazkov> | okay. what's the alternative? |
| 18:00 | <smaug____> | one alternative is to not support that at all |
| 18:00 | <smaug____> | and just have simple event propagation |
| 18:01 | <dglazkov> | but then you'll have hacks built by developers trying to solve the problem I stated just a few seconds ago -- and more than likely breaking encapsulation |
| 18:01 | <smaug____> | well, it is a hack that one needs to add listeners to the insertion point |
| 18:02 | <dglazkov> | smaug____: how so? |
| 18:02 | <smaug____> | because the event propagation is not working the usual way |
| 18:02 | <dglazkov> | sure, but it's not because we're just being fun silly peeps. It's because we're solving a real problem. |
| 18:03 | smaug____ | would like to see some real use cases which have lead to the current design |
| 18:03 | <dglazkov> | if you have a tabstrip custom element, and tabs are distributed into an insertion point, how would your tabstrip know if a tab was clicked on? |
| 18:04 | <smaug____> | you have just one insertion point, so everything works naturally |
| 18:05 | <smaug____> | clicks propagate via insertion point to the tabstrip's shadow dom |
| 18:05 | <smaug____> | and then out to the non-shadow dom |
| 18:06 | <smaug____> | you can have listeners anywhere in the tabstrip's shadow dom |
| 18:07 | <smaug____> | (XBL1 has managed to live without shadow dom's complicated event propagation just fine) |
| 18:09 | TabAtkins | wouldn't describe much of XBL1 as "fine". |
| 18:10 | <smaug____> | TabAtkins: shadow dom isn't really much different to xbl1 |
| 18:11 | <smaug____> | a bit different syntax |
| 18:11 | <smaug____> | s/a bit// |
| 18:11 | <smaug____> | better spec |
| 18:12 | <smaug____> | and hopefully shadow dom will have better implementations than what xbl1 has had |
| 18:20 | <dglazkov> | smaug____: the best way to think of it is that insertion point is distributed along with the node. Then everything makes sense. |
| 18:21 | smaug____ | tries :) |
| 18:21 | <smaug____> | ok, if insertion point is removed from its parent |
| 18:22 | <dglazkov> | also, hayato is da man. He wrote most of the new spec anyway. Including the graphs |
| 18:23 | <dglazkov> | and implementation in blink |
| 18:23 | <smaug____> | k |
| 18:23 | smaug____ | should wake up early and find hayato |
| 18:23 | <Ms2ger> | Has anyone else read the spec? :) |
| 18:23 | <smaug____> | Ms2ger: probably not |
| 18:24 | <smaug____> | (use of undefined variables hints that) |
| 18:24 | <dglazkov> | smaug____: that's because he's rewriting it. I am sure the later sections are completely messed up right now |
| 18:25 | <smaug____> | actually, wchen must have read some version of it, since he wrote a patch I should review |
| 18:25 | <smaug____> | but can't review before I understand the spec, and reasoning behind it |
| 18:26 | <dglazkov> | smaug____: I understand. sorry I wasn't as helpful :-\ |
| 18:26 | <dglazkov> | I used to be awesome. |
| 18:26 | <smaug____> | dglazkov: you were helpful |
| 18:26 | <dglazkov> | but now I am just great |
| 18:26 | <smaug____> | dglazkov: you are awesome! :) |
| 18:27 | <dglazkov> | smaug____: no, _you_ are awesome! :P |
| 18:27 | <dglazkov> | specifically for reviewing the wchen's patch |
| 18:27 | <smaug____> | I'm just a person who complains about specs but makes sure to never write one himself |
| 19:21 | <Hixie_> | man, some of the sentences i write become silly |
| 19:21 | <Hixie_> | "the foo of the bar of the foo that is associated with the quux specified by the bar of the foo's bar..." |
| 19:41 | <matjas> | Hixie: this is why {reading,writing} specs is hard |
| 20:00 | <hober> | Hixie_: along those lines, i think my favorite sentence of yours is "If there is a position to which the boxes in boxes can be moved while maintaining the relative positions of the boxes in boxes to each other such that none of the boxes in boxes would overlap any of the boxes in output, and all the boxes in output would be within the video's rendering area, then move the boxes in boxes to the closest such position to their current |
| 20:00 | <hober> | position, and then jump to the step labeled done positioning below." |
| 20:27 | <Hixie_> | hober: yikes |
| 20:39 | <Hixie_> | oh ho ho |
| 20:40 | <Hixie_> | firefox doesn't actually throw here... |
| 20:40 | <Hixie_> | nor does safari... |
| 20:40 | <Hixie_> | i like it when i find writing the spec is hard and so i check the browsers again and find that what some of them do is simpler to spec |
| 23:04 | <Hixie_> | abarth: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 |
| 23:04 | <abarth> | Hixie_: hi |
| 23:04 | <abarth> | ok, i'll read up on the thread |
| 23:28 | <abarth> | Hixie_: done |