| 00:35 | <Hixie> | MikeSmith: see my google+ post :-) |
| 00:37 | MikeSmith | reads |
| 00:39 | <MikeSmith> | so one quick thing I can tell you is that on almost all Japanese IMEs I have used on mobile devices, there are no separate hiragana and katakana modes |
| 00:40 | <MikeSmith> | there's only general kana mode, alphabet mode, and number mode at the base |
| 00:41 | <MikeSmith> | and usually a separate symbol mode for typing in emoticons and special characters |
| 00:43 | <MikeSmith> | I'll try to make some screenshots today and annotate them |
| 00:43 | <MikeSmith> | I have three different Japanese IMEs installed on my Android mobile, and that's the common case for all of them |
| 00:44 | <MikeSmith> | I guess I should buy ATOK and take a look at that |
| 00:45 | <espadrine`> | gsnedders: do you know anything about DOM properties that are enumerable, but are not on the prototype chain? Is that considered a bug? |
| 00:45 | <MikeSmith> | ah cool they have a trial version |
| 00:47 | <hober> | people still use google+? |
| 00:47 | <espadrine`> | gsnedders: I noticed that Opera doesn't have any, but Firefox and Chrome have a bunch. |
| 00:48 | <divya> | shhh hober |
| 00:49 | hober | forgot to use his inner monologue |
| 00:50 | divya | offers to be hober's conscience |
| 00:51 | <MikeSmith> | hey I need a conscience too |
| 00:51 | <MikeSmith> | at least that's what some people tell me |
| 00:53 | <hober> | yeah, i think MikeSmith is ahead of me in the getting-a-conscience queue, divya |
| 00:53 | <zewt> | MikeSmith: that's pretty odd (no hiragana/katakana toggle); does it depend on heuristics to convert or are people just OK with that? |
| 00:54 | <divya> | but you are in sf hober ! I can pretty much do that job IRL too. |
| 00:54 | <divya> | MikeSmith: i shall be your conscience digitally |
| 00:55 | <MikeSmith> | divya: :) |
| 00:55 | <MikeSmith> | zewt: it includes both the hiragana and katakana in the candidate lists it gives back |
| 00:55 | <zewt> | some of those jp ime's are weirdo |
| 00:56 | <zewt> | i guess plenty of western inputs are weirdo too (swype, etc) |
| 00:57 | <MikeSmith> | I really like swype |
| 00:57 | <MikeSmith> | swype has a Japanese IME too |
| 00:57 | <MikeSmith> | but it doesn't work nearly as well as the English one |
| 01:35 | <MikeSmith> | Hixie: http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control#Android_Japanese_IMEs |
| 01:38 | <espadrine`> | gsnedders: related to the prototype-invisible properties issue, here's the data I have, and some code to fiddle with: http://3.jsbin.com/ebukuv/2/edit |
| 01:42 | <Hixie> | MikeSmith: thanks man |
| 01:43 | <Hixie> | hober: keeps growing, see our i/o announcements :-D |
| 01:44 | <MikeSmith> | Hixie: if you want screenshots of submodes lemme know but really those are the same as as with other IMEs. Well except that there are a bunch of different subcategories of emoji. But I don't think anybody wants to have separate input modes for those subcategories. |
| 01:46 | <Hixie> | MikeSmith: you describe four modes but have three pictures -- can you clarify which relates to which? |
| 01:47 | <MikeSmith> | Hixie: those are three different IMEs: the first is one called ATOK that's very commonly used, the second is Google Japanese, and the third is the IME that's built-in on Samsung mobiles |
| 01:47 | <Hixie> | aah, ok |
| 01:47 | <Hixie> | they all correspond to "normal" mode? |
| 01:47 | <MikeSmith> | they're all shown in kana mode |
| 01:47 | <Hixie> | ah cool |
| 01:47 | <Hixie> | thanks |
| 01:48 | <Hixie> | MikeSmith: so there's no separate "kanji" mode or whatnot? |
| 01:48 | <MikeSmith> | you can see they're all basically the same: you have one button for switching among あ-A-1, and one other button with a smiley face for getting emoticons and symbols |
| 01:48 | <MikeSmith> | no there is no separate kanji mode |
| 01:49 | <MikeSmith> | making the kanji is a two-step process that starts by typing in kana |
| 01:49 | <MikeSmith> | so there is no need for a kanji mode in addition to kana mode |
| 01:49 | <MikeSmith> | they're the same thing |
| 01:50 | <MikeSmith> | and same goes getting katakana actually |
| 01:50 | <MikeSmith> | you have to first time in hiragana |
| 01:50 | <MikeSmith> | on mobile IMEs that is |
| 01:50 | <Hixie> | MikeSmith: so just the same ones as western IMEs (normal, numeric, e-mail, url, telephone), with submodes like symbols/emoji, and then the additional mode for specifically entering in "latin" input? |
| 01:50 | <MikeSmith> | on desktop IMEs there are usually a separate katakana mode |
| 01:50 | <MikeSmith> | Hixie: yeah |
| 01:50 | <Hixie> | k |
| 01:50 | <Hixie> | that's surprisingly mundane and restrained for the japanese :-P |
| 01:51 | <MikeSmith> | heh |
| 01:51 | <Hixie> | i guess they let loose in the emoji submodes... |
| 01:51 | <MikeSmith> | yeah |
| 01:51 | <Hixie> | thanks a ton for this |
| 01:51 | <Hixie> | you are so far basically the only person to give me any information :-) |
| 01:51 | <MikeSmith> | those have separate subcategories for emotions for laughing, for crying, for being angry, etc. |
| 01:52 | Hixie | has seen the unicode emoji pages, good lord |
| 01:52 | <MikeSmith> | Hixie: somebody else put up iOS screenshots there |
| 01:52 | <MikeSmith> | yeah actually before when I said emoji I meant emotions |
| 01:52 | <MikeSmith> | *emoticons |
| 01:52 | <Hixie> | i put the ios ones up :-( |
| 01:52 | <MikeSmith> | ah |
| 01:53 | <MikeSmith> | on Android smartphones at least there is not way to type in all those unicode emoji, or the emoji that we have on legacy keitai mobiles |
| 01:53 | <Hixie> | (found them on some stackoverflow question) |
| 01:53 | <Hixie> | oh really? |
| 01:53 | <Hixie> | interesting |
| 01:53 | <MikeSmith> | yeah |
| 01:54 | <MikeSmith> | it's one of the fun Japanese things that's lost in going to smartphones |
| 01:54 | <Hixie> | does android have much penetration? |
| 01:54 | <MikeSmith> | yeah very much |
| 01:54 | <MikeSmith> | Docomo has tons of different Android devices, and the number two carrier Au does too |
| 01:56 | <Hixie> | weird, i thought not having emoji was considered a blocker to deployment in .jp and that was used as the argument for adding the six zillion pages to unicode |
| 01:57 | <zewt> | are you sure? |
| 01:57 | <zewt> | i'd think it's more round-trip compat with sjis or something like that |
| 01:58 | <MikeSmith> | it does suck to not have them. I used to use them all the time in mobile e-mail messages |
| 01:58 | <MikeSmith> | beer glass, hypodermic needle, etc. |
| 02:00 | <MikeSmith> | a wait they are still there, but only in the e-mail client |
| 02:00 | <Hixie> | they're the only part of unicode that specifies actual _colours_ |
| 02:00 | <MikeSmith> | being only available in mobile e-mail makes sense because that's the only place you could reliably use them anyway |
| 02:01 | <MikeSmith> | I just don't notice because I avoid using Docomo's mobile e-mail client because it's so bad and painful to use |
| 02:04 | <MikeSmith> | anyway for all those emoji characters I don't think anybody would want a separate way to specify an emoji inputmode for form fields in Web applications. Because you never want to start out typing in emoji. You use the emoji to decorate your prose. |
| 02:04 | <Hixie> | oh yeah i wasn't suggesting anyone would want that |
| 02:06 | <Hixie> | MikeSmith: is there a concept of a difference between a text field with capitalisation or not, the same way there's a concept of a difference between message text fields and username text fields in the west? |
| 02:06 | <Hixie> | for kana input, i mean |
| 02:07 | <MikeSmith> | anyway to be clear again what I said before about emoji not being available on smartphones as wrong. It's still available in the same one place it's always been, in the carrier-specific mobile e-mail clients. But it's not available in Gmail and such so I think since many more people here are just using Gmail they don't use emoji in their messages. |
| 02:08 | <MikeSmith> | Hixie: no concept of a difference in capitalization for Japanese/kana mode |
| 02:08 | <Hixie> | how about a way to turn off the ability to upconvert from hiragana to kanji or katakana? |
| 02:08 | <Hixie> | any fields that prevent that? |
| 02:08 | <MikeSmith> | no not that I know of |
| 02:08 | <Hixie> | very interesting |
| 02:08 | <MikeSmith> | what use case relates to that? |
| 02:08 | <Hixie> | no idea |
| 02:08 | <Hixie> | i'm mostly stumbling in the dark here |
| 02:09 | <MikeSmith> | at some point you'll probably want to try to get more details from a Japanese native speaker/user |
| 02:10 | <Hixie> | that's what my g+ post was attempting to get :-) |
| 02:10 | <Hixie> | i should record another video for those guys who sent me a book |
| 02:10 | <Hixie> | "hello hero worshippers! i have a mission for you now!" |
| 02:10 | <MikeSmith> | ahaha |
| 02:11 | <MikeSmith> | hey a good source to get info from at Google Japan is Hiroyuki Komatsu |
| 02:11 | <MikeSmith> | he leads the product-dev team for Google Japanese IME |
| 02:11 | <Hixie> | i asked internally at google too (on our internal g+), will see what response i get overnight and poke people if i don't |
| 02:12 | <MikeSmith> | talk to Takuya Oikawa if you know him |
| 02:12 | <MikeSmith> | he can put you in touch with Komatsu-san or whoever |
| 02:12 | <MikeSmith> | or ask Fette because he knows all these guys too |
| 02:13 | <MikeSmith> | Or Dominic Clooney |
| 02:13 | <Hixie> | my office is literally four meters from the i18n team |
| 02:13 | <Hixie> | so i'm good |
| 02:13 | <Hixie> | (not that i ever go to that building) |
| 02:13 | <MikeSmith> | ok |
| 02:13 | <Hixie> | (but that's another story) |
| 02:20 | <Hixie> | so i guess the "normal" mode should just be "user default", and japanese just adds one extra mode |
| 02:20 | <Hixie> | and "capitalise" mode should be "latin captitalise" and "prediction off" should be "latin without prediction" and so on |
| 02:21 | <Hixie> | i guess it depends a lot on what other languages want |
| 02:21 | <Hixie> | but my point basically is that xforms' model is apparently wrong |
| 02:21 | <Hixie> | and rather than script * mode, it's just a list of modes |
| 02:33 | <zewt> | android is really annoying, it tends to merge "autocapitalization" and "prediction" into a single setting |
| 02:33 | <zewt> | so I can't get IRC with prediction/autocorrection but without autocap |
| 03:11 | <MikeSmith> | Hixie: yeah the Xforms model doesn't match anything except some twinkle in the eye of an architecture astronaut |
| 03:12 | <Hixie> | yeah, seems that way |
| 03:12 | <MikeSmith> | and yeah to be clear there is no way to turn off prediction in Japanese mode. The prediction in that case is really more like completion and is fundamental to the way the whole thing works. |
| 03:13 | <MikeSmith> | that said, sometimes the IME prediction conflicts with stuff like Google Suggest so it would be good to have a way to disable the system IME sometimes |
| 03:14 | <MikeSmith> | but that's what the IME API spec is attempting to do (in part) |
| 03:14 | <Hixie> | not sure what disabling the IME altogether would mean, without script, but with script i'd presume the API would turn off the system-level stuff, yeah |
| 03:15 | <MikeSmith> | zewt: about no auto-caps for me at least I get more sane behavior for that in Swype. Or it seems like at least |
| 03:15 | <zewt> | yeah just talking about the default latin input |
| 03:16 | <zewt> | MikeSmith: if google suggest is broken by "people inputting japanese", isn't effectively disabling japanese input the wrong solution? :) |
| 03:17 | <MikeSmith> | lemme get a screenshot to show what I mean |
| 03:18 | <MikeSmith> | it's a problem of the system-IME candidate list obscuring the Google Suggest candidate list |
| 03:18 | <zewt> | google search is much less polished than it used to be; for example, pressing arrows while its suggestion dropdown is displayed operates on keyup (instead of down) and doesn't key repeat--very rough stuff |
| 03:18 | <zewt> | MikeSmith: wouldn't the solution be a hint of where you want IME overlays to go? i think most mature ones have something like that |
| 03:18 | <zewt> | "i need the space below the input box, so try to put stuff on top" |
| 03:23 | <MikeSmith> | this: http://people.w3.org/mike/mobile-ime/ime-conflict.png |
| 03:23 | <Hixie> | heh |
| 03:24 | <Hixie> | oops |
| 03:24 | <MikeSmith> | there are Google Suggest candidates that are obscured by the system IME |
| 03:24 | <zewt> | MikeSmith: but given the two, isn't the IME the more important thing to see? |
| 03:24 | <MikeSmith> | so to get to them I have to either drag the system IME window out of the way, or scroll the page |
| 03:24 | <zewt> | of course, the IME should go away once you pick something... |
| 03:24 | <MikeSmith> | zewt: no actually it's often not |
| 03:24 | <MikeSmith> | yeah it does do that at least |
| 03:25 | <zewt> | how can you even use the IME if there's no completion? |
| 03:25 | <zewt> | unless you happen to get what you want on the first guess |
| 03:25 | <MikeSmith> | you do usually, with Google Suggest at least |
| 03:26 | <MikeSmith> | it is much more often the case that you want to see the smart Google Suggest candidates rather than the generic system IME ones |
| 03:30 | <MikeSmith> | zewt: I'm not sure what the best behavior would be, but I think maybe having the system IME on when you compose the first clause and then turning it off until you start to type another clause |
| 03:30 | <MikeSmith> | if you see what I mean |
| 03:30 | <zewt> | are there any use cases other than gsuggest (out of curiosity)? |
| 03:31 | <MikeSmith> | i need the IME on to do the initial composition but once I've stopped typing I don't need that candidate window from the system IME |
| 03:31 | <MikeSmith> | zewt: yeah Bing |
| 03:31 | <MikeSmith> | same problem |
| 03:31 | <MikeSmith> | or any Web app that has as similar suggest feature |
| 03:32 | <MikeSmith> | it's a general problem and was one of the primary cases if not the primary case for coming up with the IME API |
| 03:37 | <zewt> | well, most autocomplete dropdowns in web apps aren't smart enough to work for japanese without the native IME's help for kanji, but okay |
| 03:38 | <zewt> | the high-profile ones (search engines, amazon) are |
| 03:41 | <MikeSmith> | zewt: yeah that's the use case we had in mind anyway |
| 03:42 | <MikeSmith> | those are the ones that cause the widest user frustration |
| 04:09 | <MikeSmith> | hey it's abarth in a video http://www.youtube.com/watch?v=EDtiWN42lHs |
| 04:16 | <MikeSmith> | wtf <browser src="http://news.google.com/"; width="640" height="480"></browser> |
| 04:16 | <MikeSmith> | http://code.google.com/chrome/extensions/trunk/apps/app_external.html#H3-4 |
| 04:16 | <MikeSmith> | and <a name="H3-4"></a> in the source |
| 04:17 | <MikeSmith> | "Unlike iframes, the browser tag runs in a separate process." |
| 04:18 | <zewt> | why would authors care? |
| 04:18 | <MikeSmith> | security for installed apps |
| 04:19 | <MikeSmith> | it's not for the Web I guess |
| 04:19 | <MikeSmith> | but for the un-Web |
| 06:31 | <hsivonen> | what's the typical connotation of the meme picture at http://w3cmemes.tumblr.com/post/27558722901/stereotypical-html-wg-poll-respondent ? |
| 06:32 | <Hixie> | it's the background of advice animal memes |
| 06:32 | <Hixie> | thus the implication is "nothing" or "nobody" |
| 06:34 | <hsivonen> | Hixie: I see |
| 06:36 | <hsivonen> | sigh. Web and TV IG is confidential |
| 06:37 | <hsivonen> | and they are supposed to request features for HTML video, right? |
| 06:37 | <Hixie> | haven't they already requested all the features they want? |
| 06:37 | <Hixie> | one presumes they have been requesting them in order of priority |
| 06:37 | <hsivonen> | Hixie: maybe |
| 06:37 | <Hixie> | and some of there requests are pretty far down what i would consider the priority list |
| 06:38 | <hsivonen> | What's Browser Testing and Tools? Should I go observe their meeting at TPAC? |
| 06:38 | Hixie | is going to assume the question about whether someone should do something at TPAC is not aimed at him :-P |
| 06:41 | <annevk> | is there some deadline for TPAC coming up? |
| 06:41 | <hsivonen> | the TPAC registration form could use some "is the logged-in person an AC rep" logic |
| 06:41 | <annevk> | I kind of want to go, but I also kind of not want to pay a whole lot for doing so |
| 06:41 | <hsivonen> | annevk: DL coming up on Oct 16 |
| 06:42 | <annevk> | thanks |
| 06:42 | <annevk> | sounds like I have plenty of time then |
| 06:42 | <MikeSmith> | hsivonen: Browser Testing and Tools is really just for the WebDriver API at this point |
| 06:43 | <MikeSmith> | I wrote the charter in a way that will let us add more to that group if we want |
| 06:43 | <MikeSmith> | but right now it's exclusively about WebDriver |
| 06:43 | <MikeSmith> | if you know David Burns he can tell you more and help you decide if it's worth your time |
| 06:44 | <Hixie> | charters should have more distributed extensibility |
| 06:44 | <MikeSmith> | heh |
| 06:44 | <Hixie> | and with that, i bid you all adieu for the evening! |
| 06:44 | <MikeSmith> | wow Hixie quitting before midnight |
| 06:44 | <MikeSmith> | that's a rarity |
| 06:44 | <hsivonen> | MikeSmith: thanks. So I won't observe that. |
| 06:44 | <MikeSmith> | hsivonen: nn |
| 06:44 | <MikeSmith> | oops |
| 06:45 | <MikeSmith> | Hixie: nn |
| 06:45 | <MikeSmith> | hsivonen: OK |
| 06:45 | <MikeSmith> | hsivonen: I'm not sure we'll actually be having a f2f at TPAC anyway |
| 06:45 | <MikeSmith> | for that group |
| 06:45 | <hsivonen> | huh. TAG is confidential even though www-tag isn't |
| 06:46 | <MikeSmith> | TAG meetings have always been confidential I thought |
| 06:46 | <hsivonen> | ok |
| 06:46 | <annevk> | there's tag⊙wo too |
| 06:46 | <MikeSmith> | Browser Testing and Tools WG is essentially chair-less right now |
| 06:47 | <MikeSmith> | if anybody would like to volunteer |
| 06:47 | <MikeSmith> | in the mean time I guess I have to be the one to respond to the TPAC survey for the group |
| 06:47 | <MikeSmith> | hsivonen: URL for the survey? |
| 06:48 | <hsivonen> | MikeSmith: https://www.w3.org/2002/09/wbs/35125/TPAC2012/?login |
| 06:48 | <MikeSmith> | thanks |
| 06:53 | <MikeSmith> | hmm I guess the fact the group is already listed in the survey means somebody must have already requested space for a f2f |
| 08:03 | <annevk> | http://blog.whatwg.org/html-and-html5 |
| 08:03 | <annevk> | Hixie: ^^ |
| 08:04 | <annevk> | oh Hixie is asleep, can someone else do a quick review? |
| 08:06 | <hsivonen> | annevk: looks ok. |
| 08:06 | <annevk> | thanks |
| 08:24 | <hsivonen> | I foresee great implementor interest and success: http://tools.ietf.org/html/draft-karcz-uuas-00 |
| 08:41 | <MikeSmith> | hsivonen: oh boy |
| 08:46 | <odinho> | http://drupal.org/node/1170478 <-- So drupal is meditating wether to put in a <picture> polyfill into their core. That would really be disastrous. |
| 08:47 | <MikeSmith> | odinho: yeah |
| 08:48 | <odinho> | I like more and more having srcset WITH the viewport declarations, and then having <img src="balbla" defer> for more advanced usage. |
| 08:48 | <MikeSmith> | I like whatever ends up getting shipped natively |
| 08:49 | <odinho> | Yes, I like that most :P |
| 08:49 | <odinho> | But seeing that drupal page, -- people really do like flexibility. And I like simplicity. |
| 08:50 | <odinho> | Having something like @defer would allow the flexibility whilst also being very very simple. |
| 08:51 | <MikeSmith> | advocating indignantly for certain syntax is almost as good a way to spend time as arguing for particular/more semantic elements |
| 08:53 | <odinho> | MikeSmith: Well, the behaviour is starkly different. |
| 08:53 | <odinho> | It is not about syntax. It's about who gets the power to decide what is best for the user. If it is the web page author, or the user agent. |
| 08:56 | <MikeSmith> | yeah I understand that part |
| 08:57 | <MikeSmith> | but if somebody believes that unilaterally implementing it in drupal is going to somehow push browser projects to implement it the way they want, I guess they are going to be in for further disappointment |
| 08:59 | <odinho> | I'm afraid it's doing more hurt, -- vendors have to think about being compliant with how it is used in Drupal. And so it might cripple the possible usage and flexibility for the spec down the road. |
| 09:00 | <abarth_> | browser vendors will just pick a different name |
| 09:00 | <abarth_> | to avoid the baggage |
| 09:01 | <odinho> | Yea, most possibly, if going down that route of having a new image element. |
| 09:01 | <odinho> | But seems like drupal doesn't understand that. |
| 09:01 | <odinho> | They think they'll get browser support "for free" in the future. :-) |
| 09:01 | <abarth_> | glhf |
| 09:02 | <abarth_> | it worked for json.js |
| 09:02 | <abarth_> | so, it's not impossible |
| 09:02 | <abarth_> | just difficult |
| 09:02 | <odinho> | Yes. :-) But they had a spec from the start. |
| 09:02 | <odinho> | Not just some strawman proposals. |
| 09:02 | <odinho> | "it could look like this", with lots of open holes. :] But yes, it might work, if if if . |
| 09:03 | <abarth_> | i'm actually shocked the json.js think worked out ok |
| 09:03 | <abarth_> | thought we'd have tons of pain with folks using loose JSON syntax |
| 09:03 | <abarth_> | but it seems to have worked |
| 09:04 | <hsivonen> | abarth_: IIRC, adding JSON.parse to Firefox broke Facebook |
| 09:04 | <annevk> | odinho: so Drupal no longer really cares about validator conformance? |
| 09:04 | <MikeSmith> | yeah but this is about markup so there's a broader set of people with opinions about it |
| 09:04 | <hsivonen> | abarth_: fortunately, Facebook is exceptionally responsive to problems like that |
| 09:05 | <hsivonen> | abarth_: I don't expect the same responsiveness from Drupal |
| 09:05 | <annevk> | yeah Facebook is awesome |
| 09:05 | <abarth_> | hsivonen: oh, I didn't know that |
| 09:05 | <odinho> | annevk: "It will be valid in the future, so it's okay!" |
| 09:05 | <abarth_> | yeah, Facebook has a good deployment process |
| 09:05 | <hsivonen> | even if the Drupal core team was responsive, it would be a pain to get the update deployed everywhere |
| 09:05 | <odinho> | annevk: They said that in thet thread :] |
| 09:05 | <annevk> | odinho: brilliant |
| 09:06 | <MikeSmith> | abarth: speaking of new elements, you all's <browser> element looks intriguing |
| 09:06 | <annevk> | odinho: but then Drupal added RDFa too I think |
| 09:06 | <MikeSmith> | abarth: nice video btw |
| 09:06 | <annevk> | odinho: full of silly |
| 09:06 | <hsivonen> | yeah, don't trust Drupal on the future of markup |
| 09:06 | <MikeSmith> | annevk: <menuitem> |
| 09:08 | <abarth> | MikeSmith: thanks |
| 09:08 | <abarth> | yeah, the browser tag is something Firefox has had for a while |
| 09:08 | <MikeSmith> | oh |
| 09:08 | <MikeSmith> | didn't know |
| 09:08 | <MikeSmith> | I thought you all had minted it |
| 09:08 | <abarth> | well, its only exposed to "chrome" content in Firefox |
| 09:09 | <MikeSmith> | yeah I know |
| 09:09 | <abarth> | the trick with this sort of thing is to get the API right |
| 09:09 | <hsivonen> | abarth: we have <browser> for HTML??? I thought only XUL |
| 09:09 | <abarth> | yeah, XUL |
| 09:10 | <hsivonen> | If I understand correctly, the Gaia browser will use a special iframe that looks like a top-level browsing context from within |
| 09:10 | <abarth> | the problem is that iframe has the wrong API for a bunch of uses cases |
| 09:10 | <abarth> | e.g., you can't really build a browser out of it |
| 09:11 | <abarth> | I think the apps folks are going for something that has an API more like UIWebView |
| 09:11 | <abarth> | or the Android WebView |
| 09:11 | <hsivonen> | abarth: I believe there's going to be a magic attribute that morphs iframe into being more suitable |
| 09:12 | <abarth> | ok, then it might be a similar concept |
| 09:12 | <abarth> | why not use a new tag rather than morphing an iframe? |
| 09:12 | <hsivonen> | I'm not sure. I didn't participate in the design |
| 09:12 | <abarth> | in Chrome, the implementation is very different than iframe |
| 09:12 | <abarth> | it's basically a web component that hides a plugin |
| 09:13 | <abarth> | that embeds WebKit similarly to how a WebView embeds webkit |
| 09:13 | <hsivonen> | Chrome as a plug-in in Chrome? |
| 09:13 | <abarth> | yes |
| 09:13 | <hsivonen> | yo dawg |
| 09:13 | <MikeSmith> | wow |
| 09:13 | <MikeSmith> | hahaha |
| 09:13 | <abarth> | well, it even more awesome in Chrome Frame :) |
| 09:13 | <MikeSmith> | inception |
| 09:14 | <abarth> | the benefit of this technical design is that the content runs in a separate process due to out-of-process plugins |
| 09:14 | <abarth> | that means we get a strong security boundary between the app and the web content |
| 09:14 | <hsivonen> | I believe B2G runs the Gaia browser UI and the Web content in separate processes, too |
| 09:15 | <abarth> | using the morphing iframe? |
| 09:15 | <hsivonen> | so I've understood, but I'm really basing what I say on hearsay. I don't work on that stuff. |
| 09:16 | <hsivonen> | abarth: see https://wiki.mozilla.org/Security/Reviews/B2GBrowser |
| 09:17 | <abarth> | the goals are the same |
| 09:17 | <abarth> | sounds like the syntax is different |
| 09:17 | <abarth> | i'm hopeful that the SysApps WG can sort this sort of stuff out |
| 09:19 | <hsivonen> | http://mozillamemes.tumblr.com/post/27554392258/have-you-checked-out-the-source-for-the-gaia |
| 13:25 | <hsivonen> | "I couldn't find any of the original sites still responding, so it's hard to know if there is still a compat. problem here. If there isn't, the greater conceptual simplicity of the WebKit model is quite appealing." |
| 13:25 | <hsivonen> | not the first time :-( |
| 13:35 | <AryehGregor> | ? |
| 13:38 | <hsivonen> | AryehGregor: it seems to be a recurring theme that 1) Gecko does something simple. 2) Some site breaks. 3) Gecko changes to do something complicated. 4) Years later WebKit does the simpler thing. 5) The site that broke in Gecko is gone. |
| 13:38 | <AryehGregor> | Well, nothing to complain about there. We get to simplify our code, yay. |
| 13:40 | <hsivonen> | I'm slightly unhappy that Canonical introduces a system-specific notification API instead of using the multivendor API: http://developer.ubuntu.com/api/ubuntu-12.04/javascript/index.html |
| 13:41 | <odinho> | lol. Think I found a super stupid bug in testharness.js that I've been irritated by. |
| 13:44 | <Namtnad> | hsivonen: Me too. They even reinvented the notification wheel when we already have a notification spec that's already implemented. |
| 14:00 | <odinho> | https://github.com/w3c/testharness.js/pull/6 <- anyone want to r+ it quickly? :P |
| 14:58 | <gsnedders> | espadrine`: That's most certainly a bug. |
| 16:52 | <Hixie> | odinho: do you know why they don't like srcset=""? looks like it already handles their case, but maybe i'm missing something |
| 16:52 | <odinho> | Hixie: They want even more control. It's the "artistic use case" (or whatever we should call it) that is not 100% covered by that one. |
| 16:53 | <Hixie> | what more control can one have than with srcset=""? |
| 16:53 | <odinho> | Although I think that is something that will get *much* smaller usage, because it's much more specialized. |
| 16:53 | <Hixie> | (btw, on another note, http://tools.ietf.org/html/draft-karcz-uuas-00 claims to have no security implications, which is kinda funny given that this is a big part of the bits used by fingerprinting) |
| 16:54 | <Hixie> | (quite aside from the issue of speccing something without implementors, which appears to be going on here) |
| 16:54 | <odinho> | Hixie: Well, one "problem" is that it favours desktop first, over mobile first. Because the algorithm has to work (taking away pictures) from one direction. |
| 16:55 | <odinho> | Although I must confess I have mostly forgotten why they found srcset lacking at all. I was always rooted in the browser-vendor camp. |
| 16:55 | <Hixie> | not sure what you mean by "favour" |
| 16:56 | <Hixie> | the problem is intrinsically assymetric, since it's working on number lines that go from 0 to positive infinity |
| 16:56 | <Hixie> | but i don't see how that favours one side or the other |
| 16:57 | <Hixie> | i guess i should be going through this feedback, anyway |
| 16:57 | <Hixie> | got like 300 e-mails on the subject |
| 16:58 | <Hixie> | my todo list currently looks like: inputmode, autocompletetype, handlers/intents, responsive images |
| 16:58 | <odinho> | Yeah, I have written some of those :P But got a bit in need for a vacation after a bit. There's quite some repetition going on there. |
| 16:59 | <dglazkov> | good morning, Whatwg! |
| 17:00 | <Hixie> | inputmode, autocompletetype, handlers/intents, responsive images, then bugs, starting with WebVTT stuff, looks like |
| 17:01 | <Hixie> | abarth|zZz++ |
| 17:01 | <abarth> | what did I do? |
| 17:01 | <Hixie> | your e-mail just now re legacy systems |
| 17:01 | <abarth> | ah :) |
| 17:01 | <abarth> | thanks |
| 17:02 | <Hixie> | MikeSmith: so for inputmode, i'm considering having the spec define a lot of modes, but for each one say which one to fall back to if you don't support it |
| 17:02 | <Hixie> | MikeSmith: basically, a tree of modes, all but the root being optional, and the root being "user default" |
| 17:03 | <odinho> | Hixie: Well, it's mostly about things like orientation:portrait, and stuff like being able to choose between min-width and max-width. |
| 17:03 | <odinho> | Hixie: That said, towards the end of the thread tsunami, a few people started understanding the proposal better and were not so hostile any more. |
| 17:04 | <odinho> | Hixie: So I guess much of the initial reactions and emails are coming more from prejudice than actual understanding. |
| 17:05 | <[tm]> | Hixie: interesting |
| 17:06 | <Tabatkins> | odinho: Yes, nearly all of the reaction in the first 24 hours can be thrown out, as it was almost completely based on misunderstanding. |
| 17:07 | <[tm]> | different approach but seems worth exploring i guess |
| 17:07 | <Hixie> | [tm]: an alternative is to have authors list tokens, and the UA picks the first one it implements |
| 17:07 | <Hixie> | [tm]: but that seems like it would be giving authors the job that we can just do, since it's not clear that you'd ever want a _different_ fallback |
| 17:07 | <Hixie> | odinho: can you elaborate on the orientation and min vs max thing? |
| 17:10 | <[tm]> | Hixie: btw maybe you saw i added a screen capture of desktop Japanese keyboard switcher |
| 17:10 | <odinho> | Hixie: Lots of small things to tweak. I don't think anyone actually came with a really compelling case of what they wanted to do, and where the mediaqueries were a much better fit. I had an email saying how you could do min-max with srcset - response was that it was ugly :-) Which is kinda true, but well. |
| 17:15 | <odinho> | Hixie: Ah, before I thought that the max-width mediaqueries etc would work on the *content size* around it, so a picture in a small column would actually load something that only fit in there. |
| 17:16 | <Hixie> | [tm]: yeah that's what made me think of this |
| 17:16 | <Tabatkins> | It's unfortunate, but that doesn't work very well. :/ |
| 17:17 | <odinho> | But I realized that max-width in mediaqueries refer to the viewport as well, so that was my misunderstanding in the beginning about mediaqueries being more flexible and it actually having some useful flexibility. |
| 17:17 | <Hixie> | yeah we can't really do anything but viewport sizing, sadly |
| 17:17 | <Hixie> | my original idea was also based on content size but that's a nonstarer |
| 17:17 | <Hixie> | since you need to do the calculations before you have the content |
| 17:17 | <odinho> | Hixie: Unless you do it specifically for your site in script. |
| 17:17 | <Hixie> | well sure, but then you don't need any of this |
| 17:17 | <odinho> | (and to do that, you'd need to defer image load). |
| 17:18 | <Hixie> | deferring image load is easy :-) |
| 17:18 | <odinho> | Hixie: Yes, -- you want to hinder the browser from prefetching before doing javascript. |
| 17:18 | <odinho> | Hixie: well, <img data-src=img.jpg><noscript><img src=img.jpg></noscript> <-- it's very ugly. |
| 17:18 | <Hixie> | just <noscrpt><img src="..." alt="..."></noscript> |
| 17:19 | <Hixie> | script can figure out the rest |
| 17:20 | <odinho> | Yes, true :-) Hmm. |
| 17:21 | <Hixie> | or if you don't care about script-free cases and if the image is purely decorative, just something like <div data-src="..."></div> |
| 17:22 | <odinho> | Problem is that lazy-loading on scroll still poses a problem for Opera Mini. We cut execution after some seconds of js run, -- and we've had problems with many sites optimizing by lazy-loading images when you scroll down to them, and at that point, you just get white boxes, so mini breaks there. |
| 17:22 | <odinho> | Although I think Mini team has hacked around several of those things, maybe even done a real fix, I don't follow Mini too closely, just noticed breakage on my own phone some time ago. |
| 17:22 | <Hixie> | mini imho is not a conforming approach to a web browser :-) |
| 17:22 | <odinho> | WAT! :-O :P |
| 17:24 | <odinho> | But somewhat unrelated to that, - optimizing picture loading should be the user agent's job. Sadly that won't work because many sites expect pictures to be loaded before onload is fired etc. |
| 17:24 | <odinho> | So mobile browsers always load everything. |
| 17:24 | <odinho> | Having a @defer would allow to actually not to wait on those images. Even not loading them until you've scrolled down. |
| 17:25 | <Hixie> | afk bbiab to work on inputmode |
| 17:41 | <Yuhong> | After the Last Call, CSS 2.1 became CR in early 2004: |
| 17:41 | <Yuhong> | http://www.w3.org/TR/2004/CR-CSS21-20040225/ |
| 17:42 | <Yuhong> | But by the time IE7 beta 1 was released, it has been pulled back to WD: |
| 17:42 | <Yuhong> | http://www.w3.org/TR/2005/WD-CSS21-20050613/ |
| 17:42 | <Tabatkins> | Yes, CR back then was still insufficiently rigorous. |
| 17:42 | <Yuhong> | And did not become CR until after IE7 was released. |
| 17:42 | <Yuhong> | And did not become CR again until after IE7 was released. |
| 17:42 | <Yuhong> | And IE7 support of CSS 2.1 features was pretty limited. |
| 17:43 | <Yuhong> | *still pretty limited. |
| 17:43 | <Yuhong> | http://www.w3.org/TR/2007/CR-CSS21-20070719/ |
| 17:44 | <Wilto> | odinho: The current proposal for `picture` covers the min/max-width use case while using `srcset` for resolution switching only, for what that’s worth. http://www.w3.org/community/respimg/2012/06/18/florians-compromise/ |
| 17:45 | <Yuhong> | MS was working on IE8 by that time, and rewrote the CSS layout engine likely based on this CR. |
| 17:45 | <Yuhong> | Soon after IE8 was released, another CR was published: http://www.w3.org/TR/2009/CR-CSS2-20090423/ |
| 17:46 | <Yuhong> | It ended up being pulled back to WD: 20101207/ |
| 17:46 | <Yuhong> | It ended up being pulled back to WD again: http://www.w3.org/TR/2010/WD-CSS2-20101207 |
| 17:47 | <Yuhong> | But that didn't last long. |
| 17:47 | <Yuhong> | It became PR soon after IE9 was released: http://www.w3.org/TR/2011/PR-CSS2-20110412/ |
| 17:47 | <Ms2ger> | Are you trying to make a point? |
| 17:47 | <Ms2ger> | If so, make it |
| 17:48 | <Yuhong> | How IE development relates to CSS 2.1 spec development. |
| 17:50 | <odinho> | Wilto: Yes, but can you tell me what that is (with an example)? I believe you can do what you want with the current srcset proposal as well. |
| 17:52 | <Wilto> | You could for certain, but it would require a completely redundant syntax pattern. There’s no benefit to the `srcset` markup, for that purpose. |
| 17:52 | <Wilto> | For resolution switching there’s a great deal of benefit to `srcset`, both implementor and author side. |
| 17:54 | <odinho> | Wilto: No, but there's more to weigh for and against than just that case. And it's a very high price to pay for an extra convenience. |
| 17:54 | <Wilto> | What’s the benefit to using `srcset` for min/max width and such? |
| 17:55 | <Wilto> | I mean, assuming it’ll be expanded to cover both cases and units other than pixels. |
| 17:57 | <Wilto> | Just seems like a lot of reinvention for one. For another, once the appropriate _size_ image has been selected, the resolution seems like it’s better handled as an isolated concern. |
| 17:57 | <odinho> | Wilto: Plus for srcset; don't have to make a new element. Don't have to pull in the entirety of mediaqueries for picture loading (which is more work). It'll be shorter to write. With mediaqueries you *have* to follow them, with srcset the implementation can choose to optimize if it wants to (although it's not recommended to go outside the author's wishes in the common case, but uncommon cases exist). |
| 17:58 | <odinho> | Wilto: It won't be expanded for other things than pixels. Only pixels matter for screen size. |
| 17:58 | <Wilto> | I use almost strictly em-based media queries. |
| 17:58 | <Wilto> | That’s a very common practice. |
| 17:58 | <Tabatkins> | odinho: That's silly. Ems are useful for plenty of things. |
| 17:58 | <odinho> | Wilto: By the way, it can't work in media queries either when doing preloading. |
| 17:58 | <Tabatkins> | Huh? |
| 17:59 | <Wilto> | I was told several times on the mailing list that viewport information is available well before preload. |
| 17:59 | <odinho> | Tabatkins: You have to know what size the em is. |
| 17:59 | <Tabatkins> | That's well-defined. |
| 17:59 | <Tabatkins> | It's the user's default font size. |
| 17:59 | <odinho> | But it's just a constant? |
| 17:59 | <Tabatkins> | (Which you shouldn't be toying with for body text anyway, and body text em size is what you are likely breaking against if you use ems.) |
| 17:59 | <odinho> | So it won't be different from px anyway. |
| 17:59 | <Tabatkins> | It's a constant *per user*. |
| 17:59 | <Wilto> | Unless the user zooms. |
| 18:00 | <Tabatkins> | Not something the author can predict. |
| 18:00 | <odinho> | Okay, didn't know that. CSS is not my field :-) |
| 18:00 | <hober> | essentially, em=rem in mqs |
| 18:00 | <odinho> | So how would that work? |
| 18:00 | <Tabatkins> | hober: Still not right. rem can be changed by the author. |
| 18:01 | <Tabatkins> | odinho: How would what work? |
| 18:01 | <odinho> | Tabatkins: em's in srcset or in media max-width/min-width. |
| 18:01 | <odinho> | (for images, that is) |
| 18:02 | <odinho> | I've seen the behavior for mediaqueries on sites, which is kinda cool effect. :P I can't seem to apply that sensibly to the image case. |
| 18:03 | <Tabatkins> | Same deal. You may want to use different images for different breakpoints on your site. |
| 18:03 | <Tabatkins> | And if your breakpoints are em-based, which is very reasonable... |
| 18:04 | <Tabatkins> | If you're switching from a two-column to single-column layout, for example, even though you don't know exactly what size an 'em' is, you at least know that your layout is, say, 2/3rds the size that it was, and so you supply an image that's narrower. |
| 18:06 | <Wilto> | odinho: I 100% agree that the UA should have final say in the assets that get requested, though, in the case of resolution. I think `srcset` gives us a great opportunity to introduce syntax that works as… a suggestion, overrideable by the UA/users’ settings. I wouldn’t want to introduce that kind of variance to media queries either. |
| 18:07 | <Wilto> | First the correct size is selected, in absolutes. Then `srcset` determines and delivers the optimal resolution, unless overridden by the browser. “Always download high-res,” “always download low-res,” “download high-res as bandwidth permits,” etc. |
| 18:07 | <Tabatkins> | I agree that in the "art direction" case (the one that cares about min/max size), you should exactly honor what the author wants. In the "quality case" (the one that cares about resolution), you should let the UA decide what's best. |
| 18:07 | <Wilto> | Jinx, basically. |
| 18:07 | <Tabatkins> | haha, yes. |
| 18:08 | <odinho> | Designing a web site, I say <img src=myimg-2000px.jpg srcset="myimg-4000px.jpg 2x"> <-- I have a big picture there. But my phone is also 2x, and so it'll download the 4000px one, although that's grossly too much for it. |
| 18:09 | <odinho> | Pulling in the entire new tag with all its requirements feels like a very heavy handed thing to do for such a common case. |
| 18:09 | <Wilto> | I mean, buzzwords aside, there’s no denying that a single code base approach across a huge range of devices is becoming increasingly common. |
| 18:09 | <odinho> | Whilst much of the art direction and advanced usage I'm sure will see much smaller use. |
| 18:10 | <odinho> | And so that's part of the reason why I'd really like to have something short and low on requirements for that case. |
| 18:11 | <Wilto> | Well, here’s the thing, there: |
| 18:11 | <odinho> | And rather make it possible for script (or maybe even CSS) to dictate much more advanced "art direction" uses later. |
| 18:11 | <Wilto> | Your example makes perfect sense. `<img src=myimg-2000px.jpg srcset="myimg-4000px.jpg 2x">` |
| 18:11 | <Wilto> | I mean, really, I’d prefer to have that. `srcset` for resolution switching only. |
| 18:11 | <odinho> | So that it's possible to do advanced stuff again, and even in a nice way. |
| 18:12 | <Wilto> | And later on, should we need to expand to a new element for the media query use case, we’d have `srcset` already available. |
| 18:12 | <Wilto> | There’s no reason it couldn’t be used on `img` to handle the resolution-switching case alone. |
| 18:12 | <Wilto> | I would just want to avoid inventing an ever-expanding syntax for `srcset` to cover the use case better served by MQ. |
| 18:13 | <odinho> | But for mobile phones I'd really like size switching straight away. |
| 18:13 | <Wilto> | `srcset` is the better solution to resolution. |
| 18:13 | <Wilto> | Oh, trust me: so would I. |
| 18:13 | <Wilto> | I just worry that we’d paint ourselves into a corner. What if it had been implemented with pixels only, y’know? |
| 18:13 | <Wilto> | Authors would eventually just have to find ways to work around the limitations we’d stand to introduce. |
| 18:14 | <Wilto> | We’d be duplicating the uses of media queries, over time. Two syntaxes developed in parallel to accomplish the same end goal. |
| 18:14 | <Wilto> | `srcset` is a great solution for what it set out to solve: 1x, 2x, and so on. |
| 18:14 | <odinho> | Well, it would work much much better than today. Where there is *nothing*. And I'm really not convinced that pixels for images are so bad, they are made of pixels themselves. |
| 18:15 | <odinho> | Wilto: "set" set out to solve 1x 2x. srcset was to solve both resolution, and also sizes of the same image :-) |
| 18:15 | <Wilto> | If the entire page is resized in ems, though, that image is no longer layout-appropriate. |
| 18:15 | <odinho> | hober: I think you called it 'set'? |
| 18:16 | <Tabatkins> | The CSS image-set() function, you mean? |
| 18:16 | <odinho> | Tabatkins: Yea, but he sent a version for HTML as well. |
| 18:16 | <Wilto> | The original proposal that became `srcset` was `set` I think, yeah. |
| 18:16 | <Tabatkins> | Oh, yeah, right. |
| 18:16 | <Wilto> | And just solved resolution. |
| 18:17 | <Tabatkins> | odinho: You're not understanding the pixels issue. It's not very much about the image itself, it's about aligning with the breakpoints you're already defining in MQ. |
| 18:17 | <odinho> | Wilto: Not quite right either, they started out differently, but the unnamed proposal took in 'set' proposal and built on that when it came. |
| 18:17 | <Tabatkins> | And those can be defined in units other than px, and it's completely reasonable and useful to do so (not just something that's *possible* but a bad idea). |
| 18:18 | <odinho> | Wilto: hober saw Hixie was working on it, and so hober sent out his email that had been waiting as a draft. |
| 18:18 | <odinho> | Wilto: Ohwell, techincalities. |
| 18:20 | <odinho> | Tabatkins: Yea, I see that, but I'm not convinced of its weight. Some part about making the 90% of what you want to do easy, and leaving out the 10% that would steeply raise the complexity level. |
| 18:21 | <Wilto> | odinho: Raise the complexity level for authors, you mean? |
| 18:21 | <Tabatkins> | Sure, that's a valid argument in general, but the *whole point* of the art-direction side of srcset is to match your breakpoints. |
| 18:21 | <odinho> | And an easy fix like @defer would in fact be even more flexible than mediaqueries. |
| 18:21 | <odinho> | *And* it would actually be able to load images based on the *content size*. Which even mediaqueries is not able to do. |
| 18:22 | <Tabatkins> | What does <img defer> do? |
| 18:22 | <odinho> | And you could build it into your CMS in a very nice way. And do lots of nice stuff :-) |
| 18:22 | <Wilto> | Content size won’t be available at the time of prefetching, though. |
| 18:22 | <odinho> | It's the magic shampoo! :D |
| 18:22 | <Wilto> | You can’t know the available container size before the layout has been rendered. |
| 18:22 | <Tabatkins> | It's a floor wax and a dessert topping! |
| 18:22 | <Wilto> | Plus, with @defer, we lose prefetching altogether. |
| 18:22 | <odinho> | Wilto: Yes, that's what defer does, - it doesn't prefetch the image, but lets early javascript handle it in any way it wants. |
| 18:23 | <odinho> | Wilto: We didn't have prefetching until not so long ago. |
| 18:23 | <odinho> | Wilto: And @defer would be an opt-in. |
| 18:23 | <odinho> | Also, many sites do @defer on their own now, -- by using <div>'s and exchanging them with images when you scroll to them (and fades them in). |
| 18:24 | <Wilto> | Oh, yeah, we did something similar with Picturefill. |
| 18:24 | <Wilto> | https://github.com/scottjehl/picturefill |
| 18:24 | <Wilto> | I mean, that’s no long term solution, for obvious reasons. |
| 18:24 | <odinho> | Wilto: That is something I've looked at and thought about when discussing defer. |
| 18:25 | <Wilto> | Don’t get me wrong: I like the idea of having defer available. |
| 18:25 | <Wilto> | But I think you’re just gonna end up with a bunch of authors writing their own Picturefills. |
| 18:25 | <odinho> | Many mobile sites defer images already, -- it should be up to the browser to do that. Sadly it's not possible to do that (Opera tried) because the web expects every image to be loaded and ready when you fire onload. |
| 18:26 | <odinho> | Wilto: Defer would work something like picturefill on its own. |
| 18:26 | <odinho> | Ok, my idea with it was, -- when onload *has* run, and if not some script has explicitly said that it will do the picture loading, -- the browser may load them as it pleases. |
| 18:27 | <Wilto> | That’s fair, and I think it would be a great feature. |
| 18:27 | <Wilto> | I just don’t consider it a solution for this issue in and of itself, y'know? |
| 18:28 | <odinho> | So if you do (made up) img:unloaded { opacity: 0.0 } img:loaded { opacity: 1.0; transition: opacity 1s; } then they might fade in on scroll-down just like picturefills do now. But without any javascript to delay the image load. |
| 18:28 | <odinho> | Obviously mostly mobile browsers would /maybe/ like to defer the images for loading like that. |
| 18:29 | <Wilto> | Er, Picturefill doesn’t do that. I think we might be talking about two different things. |
| 18:30 | <odinho> | Wilto: I'm thinking it would be a solution to the missing 10%, and it could possibly also enable other new features. |
| 18:30 | <Wilto> | I mean, I agree: that would be useful, but completely independent of the `picture`/`srcset` stuff. |
| 18:30 | <odinho> | Wilto: Oh, no, I was actually talking about something else now. :] |
| 18:30 | <Wilto> | Ah, okay. |
| 18:30 | <Wilto> | Yeah, I mean, I would not mind having @defer one bit, as an author. |
| 18:31 | <odinho> | I mean, having @defer to be able to do the last mile of the art directed respimg things, -- and *in the process of adding that, also getting some other new stuff for "free" (ohwell :P)* |
| 18:31 | <Wilto> | It's Not That Simple™ I'm sure, but I wouldn't be mad about it. |
| 18:33 | <odinho> | It would open up the posibility of actually doing content size dependent loads. So although those last 10% would loose prefetch, they would actually gain some extremely powerful tools. |
| 18:33 | <odinho> | s/last 10%/last 10% use cases/ |
| 18:34 | <odinho> | Not people :-) |
| 18:37 | <Wilto> | I just don’t think that’s the end-all-be-all solution people are after, nice though it would be in a lot of ways. |
| 18:38 | <hober> | odinho: my original html proposal named the attribute srcset="" |
| 18:38 | <odinho> | hober: Oh, okay. Might be the other way around then :S |
| 18:43 | <hober> | I think searching for an end-all-be-all solution is a mistake in the first place |
| 18:43 | <tantek> | `hober, I kind of stopped paying attention when people kept arguing without referring to specific use-cases. |
| 18:43 | <tantek> | re: end-all-be-all - they're not even trying to do *that* |
| 18:44 | <tantek> | if they were, they'd actually reference the "alls" |
| 18:44 | <hober> | heh |
| 18:44 | tantek | is kind of tired of feature design/invention by "intuition" |
| 18:45 | <tantek> | such made up features (without citing documented use-cases) are no better than a Volcano with a fax number (no matter how cool you think that might be) |
| 18:45 | <Wilto> | tantek: This `defer` thing, you mean? |
| 18:46 | <tantek> | Wilto - can you cite the page documenting use cases of the 'defer' thing? |
| 18:46 | <odinho> | Wat! |
| 18:46 | <tantek> | if your answer is anything other than a URL, then you're doing it wrong. |
| 18:46 | <Wilto> | Woah, tantek, that’s not my deal. |
| 18:46 | <tantek> | ;) |
| 18:46 | <Wilto> | odinho brought it up, and I didn’t say much more than “that could be cool, sure.” |
| 18:47 | <tantek> | so that's part of the problem IMHO |
| 18:47 | <tantek> | we need to not be so accepting of proposals without use-caess |
| 18:47 | <tantek> | cases even |
| 18:47 | <odinho> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034840.html |
| 18:47 | <tantek> | it's why feature bloat happens :( |
| 18:47 | <odinho> | tantek: I'm against bloat. |
| 18:47 | <tantek> | much better |
| 18:48 | <odinho> | tantek: Actually we (as in Opera) wanted to defer image loading on Mobile. |
| 18:49 | <tantek> | odinho - the scenarios described make sense and do sound related to responsive image scenarios |
| 18:56 | <tantek> | odinho, consider incorporating that use-case description into the broader set of responsive image use-cases described here: http://www.w3.org/wiki/Images |
| 18:56 | <tantek> | hopefully it will make them easier to find |
| 18:56 | <Ms2ger> | Fun, hitting ctrl+a in opera-next crashes |
| 19:00 | <tantek> | sigh, apparently /Images was too hard to find on the w3c wiki, so someone started http://www.w3.org/wiki/Adaptive_Images |
| 19:00 | <tantek> | or maybe I'm missing something? Wilto, odinho, is there a difference in framing between "responsive" images and "adaptive" images? |
| 19:01 | <Wilto> | Oh, no, both terms are used interchangeably. “Determining the most appropriate image source for the client’s capabilities,” if I had to cram it onto a business card. |
| 19:01 | <Wilto> | Which I pray I never have to do. |
| 19:02 | <Wilto> | Eesh, never seen http://www.w3.org/wiki/Adaptive_Images before. Maybe that’s an older one. |
| 19:04 | <tantek> | anyway - I leave it to those of you more passionate about the subject matter to reconcile/merge/cleanup the pages accordingly for better referencing / citability in the future (to encourage more rational discussion) |
| 19:07 | <Wilto> | Is the CG’s proposal worth posting on the WHATWG mailing list, despite “going to the HTML WG?” |
| 19:08 | <Wilto> | I’m not sure how clear that divide is supposed to be; I’m just a pixel-pusher in a strange land. |
| 19:08 | <Wilto> | I figure it’s better to have everyone on the same page rather than not, me. |
| 19:08 | <tantek> | Wilto - I'm not sure how productive the different email paths are either at this point. |
| 19:09 | <tantek> | I find put everything substantial (even disagreements) on a wiki page the best way get everyone on the same page. |
| 19:09 | <tantek> | (so to speak) |
| 19:09 | <Wilto> | (Ba-dum tss.) |
| 19:09 | <tantek> | :) |
| 19:10 | <tantek> | and then sending tweet-length emails with URL to said page is a reasonable notification mechanism to all the lists of people that care |
| 19:10 | <Hixie> | afk bbiab to work on inputmode |
| 19:10 | <Hixie> | er |
| 19:10 | <Wilto> | I mean, for the RICG’s stance, http://www.w3.org/community/respimg/2012/06/18/florians-compromise and the proposal itself at http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal are kinda the final word. I guess a quick post couldn’t hurt, there. |
| 19:10 | <Hixie> | mistype |
| 19:13 | <tantek> | great, yet another W3C wiki-silo rather than using w3.org/wiki |
| 19:13 | <Hixie> | Wilto: anything you want to have impact the whatwg spec should be discussed on the whatwg list |
| 19:13 | <tantek> | (each wiki silo requires its own login etc. - I have no idea why W3C CGs made the creation of such silos the default) |
| 19:14 | <Hixie> | Wilto: i do try to read stuff outside the whatwg list, but i only guarantee to see and respond to stuff on the list |
| 19:14 | <tantek> | Wilto - maybe add links here: http://www.w3.org/wiki/HTML/next#Multimedia |
| 19:14 | <Hixie> | (and in practice, bugs in the WHATWG product HTML component assigned to ian⊙hc in the W3C Bugzilla) |
| 19:14 | <Hixie> | (but i sometimes just close those without detailed response, unlike e-mails to the list, where i try to always give a considered response) |
| 19:14 | <Hixie> | (so if you want a response, use the list) |
| 19:15 | <Wilto> | Hixie: Yeah, understandable. I’m a little wind-swept when it comes to what goes where -- lots of advice coming from lots of people, when one just wades into this particular pool. |
| 19:16 | <Hixie> | well basically there are two specs now, the WHATWG HTML spec and the W3C HTML5 spec, and they are independent |
| 19:16 | <Wilto> | ( Guessing it’s best to not resurrect the ancient thread on the topic, too. ) |
| 19:16 | <Hixie> | you have to make your own determination abotu which spec you care about :-) |
| 19:16 | <Hixie> | if you want to affect the W3C list, you want to file a bug on the W3C spec (W3C Bugzilla, HTML WG product, HTML5 spec component) |
| 19:16 | <Wilto> | Hah—which is the one where I can use these things on a website someday? |
| 19:17 | <Hixie> | well i guarantee that on the long term the WHATWG spec will match browsers |
| 19:17 | <Hixie> | but which browsers are following, i can't say really |
| 19:17 | <Hixie> | i hope the WHATWG one |
| 19:17 | <Hixie> | but we'll see |
| 19:17 | <tantek> | Wilto, even if it isn't official, HTML5 is fairly feature frozen these days. |
| 19:17 | <tantek> | Best bet for more rapid consideration / publication of new HTML features (via a spec) is to the WHATWG. |
| 19:18 | <Wilto> | Yeah. The HTML WG was discussing this as “HTML Next,” assuring me that didn’t necessarily mean a delay in implementation. |
| 19:18 | <Hixie> | tantek: my understanding is that the W3C is expecting to do a parallel play of HTML.next sooner than they finish HTML5 |
| 19:18 | <Wilto> | But... one wonders. |
| 19:18 | <Hixie> | Wilto: well, implementations are independent of specs |
| 19:18 | <tantek> | Hixie, I expect to see the HTML.next effort adopt features developed from/in WHATWG |
| 19:18 | <Hixie> | Wilto: delay in the spec just means browsers make up their own stuff :-) |
| 19:18 | <tantek> | yeah |
| 19:19 | <Hixie> | tantek: from your lips to the working group's actions |
| 19:19 | Hixie | fails to find a good rephrasing of "to god's ears" |
| 19:19 | <tantek> | Hixie - it's certainly what I'll be contributing to the WG |
| 19:19 | <Wilto> | Yeah. There are a couple of implementors ready to haul off and do this; I just assumed it made sense to push for a spec first. |
| 19:19 | <tantek> | better to discuss more considered features rather than less developed ones |
| 19:20 | <Hixie> | Wilto: well on the whatwg side i watch the (browser) implementors closely and if they go off in one direction, the spec will follow shortly. |
| 19:20 | <Hixie> | Wilto: i always like it if they go off in the same direction as i already did with the spec, since that makes my life easier :-) |
| 19:20 | <tantek> | Wilto - your speediest chances for specification are likely to contribute to WHATWG, by whatever means the editor requests (modulo, he's been known to also accept emails with wiki page citations :) ) |
| 19:21 | <Hixie> | like i said above, if you want a response to an argument, make sure to include the argument in the e-mail :-) |
| 19:21 | <tantek> | ^^^ |
| 19:21 | <Hixie> | citing a wiki page is fine but my response will likely just be "thanks, i read the wiki page and did what i thought was best considering it" :-) |
| 19:21 | <tantek> | good to know |
| 19:22 | <Hixie> | so if you care about results rather than knowing why the results came about, that's good enough :-) |
| 19:22 | <Wilto> | Naturally—I’ll post the wiki page and I’ll be sure to include the reasoning detailed in the accompanying post. |
| 19:22 | <Hixie> | (the reason being it's hard for me to quote wiki content in e-mail) |
| 19:22 | <tantek> | providing a summary of arguments in email is probably helpful then |
| 19:22 | <Hixie> | (or rather, harder than i'm willing to bother with) |
| 19:22 | <Wilto> | http://www.w3.org/community/respimg/2012/06/18/florians-compromise/ is probably a little long and prose-y for an email. I’ll pare it down. |
| 19:22 | <Hixie> | Wilto: btw if the points have already been made in the 300+ e-mail thread, then there's no need to post them again |
| 19:23 | <tantek> | Hixie, I've come across that in other discussions too - where the barrier to quotation/citation is what appears to be limiting the discussion. |
| 19:23 | <Hixie> | Wilto: i do consider each point even if it's deeply embedded in a thread |
| 19:23 | <Hixie> | tantek: yeah |
| 19:23 | <Wilto> | Some of it was covered in Florian’s posts; not all. |
| 19:24 | <Hixie> | anyway, you have a few days, as my current priorities are inputmode, autocompletetype, handlers/intents, then responsive images, then bugs, starting with WebVTT stuff |
| 19:24 | <tantek> | so basically, if you're going to post something on a wiki page (or a blog post even), make it easily quotable/citable. this applies to both the content of the page, and perhaps a/the UI for it, which should permit easy quoting/citing on at least a section if not paragraph level. |
| 19:24 | tantek | has been working on this for his own blog/site. |
| 19:24 | <tantek> | citation UIs that is |
| 19:25 | <Tabatkins> | Yeah, once I finish my own markdown parser, I'll have easy citation-links-on-hover for paragraphs, and citation-links-all-the-time on headers. |
| 19:25 | <tantek> | Tabatkins, what does the parser have to do with UI? |
| 19:25 | <tantek> | do you have sketches of your UI you could share? |
| 19:26 | <tantek> | (I've gone through numerous iterations, it seems like a pretty challenging problem) |
| 19:26 | <tantek> | the UI part, not the parser part |
| 19:26 | <Tabatkins> | tantek: I can't easily add markup to my posts unless I have control of th eparser. Right now I just author in pure Markdown, and output the generated results. |
| 19:26 | <tantek> | are you talking about manually adding citation markup/UI on each post? |
| 19:26 | <Tabatkins> | I haven't given much thought to UI yet, since I don't have the necessary technical plumbing in place yet. |
| 19:27 | <tantek> | that sounds backwards |
| 19:27 | <Tabatkins> | Yes, for some definition of "manual". |
| 19:27 | <tantek> | the technical plumbing should be driven by what the UI needs |
| 19:27 | <Tabatkins> | The technical plumbing I'm talking about is "actually be possible to have citation links at all". |
| 19:28 | <tantek> | I actually think the lack of good citation UIs is what's driven the "share all the things" button explosion. |
| 19:28 | <Tabatkins> | Until I get that far, no reason to think too much about the UI. I've seen enough permalinks on blogs to know that reasonable UI is possible. |
| 19:28 | <tantek> | one of the reasons I don't think much of the current "intent" work is worth much (if anything) - it's solving higher level problems with fundamentally flawed approaches. |
| 19:29 | <tantek> | Tabatkins - hopefully by the time you get to that point, I'll have updated my blog and you can just steal my UI :) |
| 19:29 | <tantek> | I might even blog about it |
| 19:31 | <Hixie> | volkmar: yt? |
| 19:32 | <Hixie> | volkmar: what are the use cases for the default-all-uppercase and auto-titlecase-all-words input modes? |
| 19:33 | <volkmar> | all uppercase: some forms want that |
| 19:34 | <volkmar> | title case has no strong use cases though |
| 19:34 | <volkmar> | i don't think it will be bad to have it still |
| 19:34 | <tantek> | isn't it bad to have anything without strong use-cases? |
| 19:37 | <Hixie> | can you elaborate on the uppercase thing? |
| 19:37 | <Hixie> | what forms? |
| 19:37 | <Hixie> | do they just automatically uppercase stuff? |
| 19:37 | <Hixie> | or do they actually need to default the user to uppercase? |
| 19:38 | <Hixie> | seems like just having the form uppercase it automatically would be best |
| 19:41 | <Hixie> | my current proposal is this: http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control#Ian_Hickson |
| 19:41 | <Hixie> | it only supports english (and languages with the same needs as english, so most of europe) and japanese, because nobody else has given me any info |
| 21:02 | <Hixie> | should i use 'kana' or 'hiragana' for the keyword that corresponds to the default inputmode for japanese input, given that 'katakana' will fall back to this mode and there is no separate mode for hiragana? |
| 21:27 | <hober> | Hixie: kana |
| 21:27 | <Hixie> | hober: yeah that was my conclusion too |
| 21:32 | <hober> | i knew minoring in japanese would come in handy one day |
| 21:32 | <Hixie> | hehe |
| 21:33 | <Hixie> | give me 3 minutes and you can proof-read my inputmode text |
| 21:33 | <Hixie> | since i have absolutely no idea what i'm doing here :-) |
| 21:33 | <hober> | heh |
| 21:34 | <hober> | have you thought about how well the feature maps onto, say, how the keyboard works on the ipad? |
| 21:34 | <hober> | :) |
| 21:34 | <Hixie> | i have definitely thought about it |
| 21:34 | <Hixie> | whether that produced any useful results remains to be seen! |
| 21:35 | <hober> | fair enough :) |
| 21:35 | <Hixie> | http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control is the research |
| 21:35 | <Hixie> | which includes screenshots from iOS, MacOS, and Android |
| 21:35 | <Hixie> | regenning spec now... |
| 21:35 | <Hixie> | fixing markup errors now... |
| 21:39 | <Hixie> | hober: http://www.whatwg.org/specs/web-apps/current-work/#attr-inputmode |
| 21:45 | <Hixie> | hober: any opinions? |
| 21:46 | <hober> | looking |
| 21:48 | <hober> | i'd rather this not be used when the feature could be implicitly handled because of the type="" value |
| 21:48 | <hober> | <input type=numeric inputmode=email> |
| 21:48 | <hober> | err, type=number |
| 21:48 | <hober> | the UA knows it's a number; why present the less useful keyboard? |
| 21:49 | <Hixie> | you'll notice it only applies to type=search and type=text |
| 21:49 | <Hixie> | :-) |
| 21:49 | <zewt> | Hixie: how can you say "turn off autocapitalization, but enable spelling autocorrection" (eg. irc mode)? |
| 21:49 | <zewt> | (a lack on Android that's always annoyed me) |
| 21:50 | <Hixie> | zewt: that's "latin" (and it's present on android, it's e.g. what search uses) |
| 21:50 | <hober> | oh nice. what about <textarea>? |
| 21:50 | <Hixie> | applies to that too, yup |
| 21:51 | <hober> | ok |
| 21:51 | <hober> | cursory/initial take: looks good |
| 21:51 | <zewt> | meh i need to revert from android 4.1, it's a little faster but the ui is a bunch of little steps back (adding to a big step back) |
| 21:51 | <Hixie> | hober: awesome, thanks |
| 21:51 | <zewt> | like I hit the search box on the home page and instead of letting me type right away, there's a big delay while it loads a search app |
| 21:51 | <Hixie> | volkmar: inputmode="" is in the spec |
| 21:51 | <Hixie> | zewt: odd |
| 21:52 | <zewt> | wtf? i hit the google button and it's making me go through a WELCOME TO GOOGLE bit of nonsense |
| 21:52 | <Hixie> | what hardware? |
| 21:52 | <zewt> | nexus s |
| 21:52 | <zewt> | the google search box is now a narrow thing at the top instead of the input box |
| 21:52 | <Hixie> | ah, yeah, that might just be too old to handle jellybean fast |
| 21:53 | <zewt> | that input box, at least, doesn't use autocorrection at all (probably depends on google's suggestions to handle it) |
| 21:53 | <zewt> | i'll try in the browser |
| 21:54 | <Hixie> | hm, yeah, i guess it doesn't |
| 21:54 | <Hixie> | never noticed that |
| 21:54 | <zewt> | dunno, amazon search seems verbatim too |
| 21:54 | <zewt> | i think the input API only has "helpful stuff on" and "helpful stuff off", at least last I poked through it |
| 21:54 | <Hixie> | you must be right, android just has equivalents of verbatim and latin-prose |
| 21:54 | <Hixie> | interesting |
| 21:55 | <Hixie> | well, the spec has an in between mode, anyway, so hopefully you are happy :-) |
| 21:55 | <zewt> | yeah, one more little nudge for android to support it some day :) |
| 21:57 | <zewt> | are there use cases for actually hinting half-width katakana? |
| 21:58 | <zewt> | (possibly a question for MikeSmith et al) |
| 21:59 | <Hixie> | zewt: it's apparently common for OSes to have half-width IMEs, dunno if there's a need to hint for it though |
| 21:59 | <zewt> | yeah that's what i mean |
| 21:59 | <Hixie> | ok, bbiab. |
| 22:00 | <zewt> | same question for full-width-latin (not sure how it would be used by authors) |
| 22:01 | <gsnedders> | This strikes me as a mess, and rather exemplifies why I want a decent solution for caesura: <div class="line"><a name="li2"></a>þēod-cyninga þrym gefrūnon,</div> |
| 22:01 | <gsnedders> | That is: þēod-cyninga þrym gefrūnon, |
| 22:02 | <gsnedders> | I should just stop caring about markup. It would simplify many things. |
| 22:48 | <annevk> | what is the case for inputmode=url? |
| 22:53 | <zewt> | if you're entering a URL on a webpage then you want to be in a keyboard mode that puts eg. : and / on the front keyboard (as for how often people enter URLs except into the browser directly, dunno) |
| 22:54 | <annevk> | why would you not use type=url? |
| 22:54 | <zewt> | dunno |
| 22:55 | <annevk> | because that's really the question |
| 22:56 | <zewt> | the legacy conflation of type for both "data type" and "data contents" makes it all a little mixed up |
| 23:29 | <zewt> | gah |
| 23:30 | <zewt> | apparently there are some errors that are only shown on the old "error console" in FF and not on the web console |
| 23:30 | <zewt> | wish they'd merge those and stop having two consoles |
| 23:41 | <Hixie> | strikes me that we should probably look into how to make inputmode work for contenteditable |
| 23:41 | <Hixie> | bummer |
| 23:51 | <smaug____> | zewt: error console is very useful |
| 23:52 | <smaug____> | zewt: but sure, web page related errors should go to web console |
| 23:52 | <smaug____> | zewt: file a bug if something goes to the wrong console |
| 23:56 | <tantek> | so how about that Opus huh? http://hacks.mozilla.org/2012/07/firefox-beta-15-supports-the-new-opus-audio-format/ |
