| 02:51 | <Hixie> | hober: i think relaxed="" is a terrible idea (presumably its presence is still non-conforming, just as the lack of alt="" is non-conforming today even in the presence of <meta>), but what would stop an author from using it instead of alt="" by mistake? (e.g. through cargo culting) |
| 02:52 | <Hixie> | er, s/<meta>)/<meta>/ and s/culting)/culting))/ |
| 02:52 | <Hixie> | hober: but, if we're going to have it, could we at least make it an attribute name that conveys the problem more obviously? |
| 02:52 | <zewt> | (validators whining about @alt is a good way to get people to shrug and stick an empty alt on every image just to shut it up) |
| 02:53 | <Hixie> | that's why the spec says conformance checkers shouldn't whine about missing alt="" in a number of cases |
| 02:53 | <Hixie> | hober: e.g. call it alt-attribute-invalidly-omitted-due-to-insufficient-information-at-document-creation-time="" or some such |
| 02:55 | <zewt> | i don't know what the criteria are, but i know it's nagged me and i've shrugged and did the quick shut-up-the-validator-so-it-doesn't-drown-out-real-problems game |
| 02:55 | <Hixie> | uh, missing alt is a real problem |
| 02:56 | <zewt> | not with anything I'm doing |
| 02:58 | <Hixie> | well if you're just doing private stuff, just stick alt=bogus everywhere, sure |
| 02:58 | <zewt> | hardly private |
| 02:58 | <Hixie> | or just stick a meta=generator line and be done with it |
| 02:58 | <Hixie> | if it's not private then how is it not a real problem?L |
| 02:58 | <zewt> | what problem are you assuming affects what I'm doing? |
| 02:59 | <Hixie> | i'm assuming you either have presentational images that you're not marking as such with alt="", and thus are peppering the output for non-image-enabled-graphical-browser users with "hey there's an important image here" notifications, or |
| 02:59 | <Hixie> | that you are giving content-ful images that you aren't giving alt="..." text for and are thus making such users be unable to get the full content of the page |
| 03:00 | <zewt> | non-image-enabled-graphical-browsers are not an important category of users to most web developers |
| 03:00 | <Hixie> | ah, the elitist school of web design, i see |
| 03:00 | <zewt> | they may be important to you, but that doesn't magically make that trivially small set of users important to people spending money to have content developed |
| 03:01 | <zewt> | ah, the "developer time is free and everything I think is important is important to everyone" school of web design, I see |
| 03:02 | <zewt> | everything is a balance of priorities, and it's not "elitist" for people to have different priorities than you |
| 03:03 | <Hixie> | do you also have gender fields that only have "male" and "female" options, text that can't be zoomed, diagrams that use just red and green, name fields that require a first and last name, and no js-disabled fallback, by any chance? |
| 03:03 | <zewt> | i sure don't spend time developing for people who turn JS off |
| 03:03 | <zewt> | (the development time it takes to support that is far too severe for the userbase) |
| 03:04 | <zewt> | i don't think there's any parallel between "deliberately turns off javascript" and colorblindness, however |
| 03:04 | <Hixie> | well, i hope you work for companies my employers compete against, so i can pick up all the customers you leave behind :-) |
| 03:04 | <zewt> | sure, you can have both of them :) |
| 03:05 | <Hixie> | 6 billion * (3% + 1% + 1% + 1% + 1% + ...) ends up being plenty of people |
| 03:07 | <zewt> | i'm sympathetic to spending effort supporting people with issues they're born with (colorblindness), but less so to people who expect people to jump through hoops because of something they've done willfully (turn off images, JS, CSS) |
| 03:10 | <zewt> | (which is why I do use @alt if it makes sense, for screen readers; but blind people can't use our primary products--iOS games--anyway, so supporting that for most of our webpages is moot; priorities again) |
| 06:41 | <annevk> | MikeSmith: submitted affiliation change request |
| 06:42 | <MikeSmith> | thanks |
| 06:42 | <MikeSmith> | I will ping plh about that |
| 06:42 | <MikeSmith> | not sure how quickly he will get around to processing it, because he's at IETF in Vancouver |
| 06:42 | <MikeSmith> | and funny thing, he has been sending me some questions by e-mail now and then |
| 06:42 | <MikeSmith> | about various things |
| 06:43 | <MikeSmith> | and the funny part of it is, I can tell from the subject of the e-mails who he has been talking to at IETF |
| 06:43 | <MikeSmith> | without him needing to mention the name |
| 06:43 | <MikeSmith> | e.g., one of his questions was about the MIME sniffing draft at IETF |
| 06:44 | <annevk> | heh |
| 06:44 | <MikeSmith> | which by the way I think that's another draft we should just (re)take ownership on at this point |
| 06:45 | <MikeSmith> | I think it's a lot further along than the URL draft |
| 06:45 | <MikeSmith> | if we make it deliverable of a W3C WG I don't know which group it should go to |
| 06:46 | <MikeSmith> | but we could deal with that later |
| 06:46 | <MikeSmith> | or we just fold it back into the HTML spec where it came from |
| 07:00 | <Hixie> | MikeSmith: i think adam was planning on just doing that one through whatwg, i really need to get my act together in terms of making a page to put those |
| 07:01 | <MikeSmith> | ok |
| 07:01 | <MikeSmith> | I know Adam has zero plans to continue it at IETF |
| 07:03 | <Hixie> | right |
| 07:14 | <annevk> | there is http://mimesniff.spec.whatwg.org |
| 07:14 | <Hixie> | yeah |
| 07:14 | <Hixie> | it's not properly tied into everything |
| 07:15 | <annevk> | our spec organization is a bit of a mess still |
| 07:15 | <Hixie> | so earlier i suggested alt-attribute-invalidly-omitted-due-to-insufficient-information-at-document-creation-time="" as the attribute name for relaxed="" |
| 07:15 | <Hixie> | obviously that's a non-starter |
| 07:16 | <Hixie> | but how about no-alt-available-at-publication-time="" ? |
| 07:17 | <MikeSmith> | I could live with that |
| 07:17 | <Hixie> | or user-provided-image-without-alt="" |
| 07:18 | <MikeSmith> | I agree it's good to make it a more obviously discouraging attribute name |
| 07:18 | <MikeSmith> | the "user-provided" part seems kind of ambiguous (which user?) |
| 07:18 | <Hixie> | image-contents-unknown="" ? |
| 07:19 | <MikeSmith> | generator-provided-image-without-alt |
| 07:19 | <Hixie> | generator-provided-image-without-alt="" isn't bad |
| 07:20 | <Hixie> | or generator-provided-image-with-missing-alt="", to underscore that the alt is missing, not just omitted |
| 07:20 | <MikeSmith> | yes |
| 07:20 | <Hixie> | maybe generator-unable-to-provide-alt="" |
| 07:21 | <MikeSmith> | perhaps |
| 07:21 | <annevk> | back later |
| 07:21 | <MikeSmith> | generator-inserted-image-without-providing-alt="" |
| 07:21 | <Hixie> | or longer, generator-unable-to-provide-required-alt="" |
| 07:21 | <MikeSmith> | yeah |
| 07:22 | <Hixie> | i like "unable" because it implies that that's a bad thing, not a choice |
| 07:22 | <MikeSmith> | yeah |
| 07:22 | <Hixie> | of course half the authors don't speak english with enough fluency to get that, and the other half don't care, but still |
| 07:22 | <MikeSmith> | I don't know if that's true, but point taken |
| 07:23 | <MikeSmith> | will be interesting to hear hsivonen current thoughts on this |
| 07:23 | <Hixie> | i think i like generator-unable-to-provide-required-alt="" |
| 07:24 | <Hixie> | the "generator" part is good as it scopes who can say it, the "unable" and "required" parts underscore that it's bad, and the length makes it stick out so it's less likely to be cargo-culted |
| 07:25 | <MikeSmith> | yeah, nobody's going to want to type that manually and it's certainly going to draw their attention in the copy-paste case |
| 07:27 | <Hixie> | yeah, discouraging manual typing, also a good point |
| 07:30 | <MikeSmith> | I think I'll add experimental support for this in my validator workspace and push it to http://qa-dev.w3.org:8888/ once I've done that |
| 07:31 | <MikeSmith> | including adding a "Report errors for img elements with an generator-unable-to-provide-required-alt attribute." option in the UI, after the current "Show Image Report" option |
| 07:31 | <MikeSmith> | with it unchecked by default |
| 07:36 | <Hixie> | btw note that Flickr isn't a use case for this |
| 07:36 | <Hixie> | Flickr is handled by one of the other escape clauses (using <figure> or title="" to give the image caption) |
| 07:38 | <MikeSmith> | OK |
| 07:38 | <Hixie> | the case we're talking about here is more for things like word-to-html |
| 07:38 | <MikeSmith> | ah yeah |
| 07:56 | <Hixie> | MikeSmith: i posted about it to whatwg |
| 07:57 | MikeSmith | takes a look |
| 08:54 | <Stevef_> | hixie: why is word to HTML a use case? alt can be specified in word |
| 09:00 | <Stevef_> | hixie: notes on effects of conversion from several formats - Accessible Documents in HTML, Word, and PDF http://terrillthompson.com/blog/25 |
| 09:01 | <annevk> | MikeSmith: btw, should we publish Notifications as Last Call? |
| 09:04 | <jgraham> | Hmm, so I am confused about base URIs + pushState. If I have <base href="base/"><a href="foobar"></a> and I pushState the URL of the link, what should the a) document location, b) document base URL and c) resolved link URL be after the pushState? |
| 09:04 | <MikeSmith> | Stevef_: for the case where the alt text is not specified in the source Word doc |
| 09:04 | <MikeSmith> | we don't validate the source Word doc |
| 09:04 | <Stevef_> | mikesmith: right |
| 09:07 | <jgraham> | TC: http://hoppipolla.co.uk/tests/pushState/001.html |
| 09:09 | <Stevef_> | mikesmith: on the generalization of a novalidate attribute, i can think of many situations where an author does not have control over parts of the code that are used in a page, example any 3rd party widget/ any mash up, it would be useful to be able to isolate those parts DOM tree and mark them as novailate, so errors in parts that the author can fix are not lost in the crowd |
| 09:09 | <MikeSmith> | Stevef_: agreed there are situations like that but I think we should deal with those on an element-by-element basis |
| 09:10 | <MikeSmith> | trying to create a general solution for what are in reality a variety of different problems is often (or usually) not the best idea |
| 09:10 | <MikeSmith> | relaxed="" is too general of a name |
| 09:10 | <Stevef_> | mikesmith: ok |
| 09:11 | <jgraham> | In particular I don't quite follow why the document base URI doesn't change (in Wecko/GeKit) when you pushState |
| 09:11 | <MikeSmith> | the right solution for img is something more specific and obvious like generator-unable-to-provide-required-alt |
| 09:17 | <Stevef_> | that could also be used as an identifier for AT to use heuristics or identify the presence of an image without announcing garbage, i could live with that |
| 09:20 | <jgraham> | annevk, hsivonen: any hints for me about base URIs? |
| 09:23 | <Stevef_> | mikesmith: in the word to HTML case any error would fall into the bucket of machine generated can't fix |
| 09:23 | <Stevef_> | mikesmith: so why provide a method to ignore alt errors only? |
| 09:27 | <MikeSmith> | Stevef_: because that is the only one we have an open issue for |
| 09:27 | <MikeSmith> | my immediate goal is to try to get agreement on a solution for that one open issue, and get it resolved so we can move on to other issues |
| 09:27 | <annevk> | jgraham: dunno, what does the spec say? |
| 09:27 | <AryehGregor> | A novalidate attribute? Like, <html novalidate> so that your page passes validation no matter what? |
| 09:28 | <annevk> | novalidate is taken by forms |
| 09:28 | <AryehGregor> | Oh, true. |
| 09:28 | <MikeSmith> | Stevef_, AryehGregor: I do not want to transform the need to resolve issue 206 into a general one-size-fits-all solution |
| 09:28 | <jgraham> | annevk: Well afaict the pushState should set the document's current address |
| 09:28 | <AryehGregor> | Regardless of name, it would make more sense for validators to still validate such portions of the page, just indicate the errors separately. |
| 09:28 | <annevk> | jgraham: okay, so then the base URL stays the same |
| 09:29 | <MikeSmith> | AryehGregor: that does not solve the problem of needing to make it obvious that an image is broken due to lack of alt text |
| 09:29 | <annevk> | jgraham: and presumably pushState resolves its argument against the base URL for the Document the script is associated with |
| 09:29 | <jgraham> | annevk: But "document base URL" should resolve the <base> element against the current address? |
| 09:29 | <annevk> | jgraham: there's no reason for document base URL to update itself |
| 09:30 | <AryehGregor> | MikeSmith, we don't want to introduce permanent new markup features without making sure they're designed to meet solid use-cases at the appropriate level of generality. A quick fix to resolve an issue makes sense for non-normative requirements, but not for introducing new attributes. |
| 09:30 | <jgraham> | annevk: Where do it say that the base URL is static? |
| 09:30 | <annevk> | jgraham: it's established once, not again and again |
| 09:30 | <MikeSmith> | AryehGregor, Stevef_: something that is not suggested in the CP but that I think should be added is, the name of the attribute should be a big red flag that indicates the img should have alt text but is missing it |
| 09:30 | <annevk> | jgraham: it's not exactly static either |
| 09:30 | <AryehGregor> | Basically, if the author can't provide alt text for an image because they didn't provide it, it's not different from embedding any invalid content, as Stevef_ points out. The validator should still raise an error in such a case. |
| 09:30 | <MikeSmith> | AryehGregor: I don't think this is a quick fix at all |
| 09:30 | <jgraham> | The "resolve a URL" algorithm makes it sound like it is resolved every time |
| 09:31 | <jgraham> | annevk: Where is this defined? |
| 09:31 | <annevk> | jgraham: I guess that is kind of buggy |
| 09:31 | <MikeSmith> | AryehGregor: i don't want to take a specific problem that we know we have for one element, and transform it into a general solution for hypothetical problems we might have with other elements |
| 09:32 | <annevk> | jgraham: it should only be updated if <base> mutates I think |
| 09:32 | <MikeSmith> | if we have similar problems with other elements, then we can introduce specific attributes for those two |
| 09:32 | <annevk> | jgraham: when defining document base URL I don't think Hixie considered pushState |
| 09:32 | <AryehGregor> | annevk, BTW, last I checked, Wikipedia still uses binary collation for (almost?) all its text columns in MySQL, because Unicode support in MySQL stinks. E.g., indexed values have a maximum length in bytes, commonly 1000 bytes in my experience. varchar(255) with four-byte UTF-8 could be a maximum of 1020 bytes, so MySQL will refuse to let you fully index such a column because it can't guarantee that it will always fit (even though it would h |
| 09:32 | <AryehGregor> | ave to be practically all non-BMP chars to go over the limit). |
| 09:32 | <MikeSmith> | right now, there are not a huge set of other similar problems that leap to me for me |
| 09:32 | <jgraham> | annevk: Sigh. OK |
| 09:33 | <AryehGregor> | MikeSmith, it's not hypothetical at all. It's very common that sites embed user-submitted HTML of all kinds. E.g., the markup of the MediaWiki interface is largely valid, but user-submitted content is all kinds of invalid. |
| 09:33 | <jgraham> | It is hard to get this stuff right when the spec is wrong (even if the spec is only wrong because implementations fail to follow it) |
| 09:33 | <AryehGregor> | (markup that's invalid in XHTML1 is generally prohibited, but there's lots of stuff that's valid XHTML1 but invalid HTML5) |
| 09:33 | <jgraham> | And even harder when Hixie is in a silly timezone |
| 09:34 | <annevk> | jgraham: well hey I helped you out ;) |
| 09:34 | <jgraham> | Yes, thanks :) |
| 09:34 | <AryehGregor> | MikeSmith, likewise blog software, forum software, etc. accepts user-submitted rich markup that might be invalid for whatever reason. In these cases, it should generally be *possible* to automatically make it valid by substituting style="" or whatever. |
| 09:35 | <AryehGregor> | (although it's a real pain in the neck for some things, like cellpadding; and impossible in general in a few cases, like <center>, due to CSS limitations) |
| 09:35 | <MikeSmith> | I understand that the general problem is not hypothetical |
| 09:36 | <Stevef_> | MikeSmith: i suggest that the resolution of the particluar issue may reside in a more general approach that covers other valid use cases |
| 09:36 | <MikeSmith> | I just can't think of many acute cases that are like the img@alt case that we have disagreement about how to deal with |
| 09:36 | <MikeSmith> | Stevef_: I am not ruling that out |
| 09:37 | <MikeSmith> | but I am also very wary of solutions that try to do that |
| 09:38 | <MikeSmith> | and please think this through |
| 09:38 | <MikeSmith> | say we make a global attribute called "novalidate" or "invalid" or whatever to flag stuff that the author knows is not valid |
| 09:39 | <MikeSmith> | what prevents authors from abusing the hell out of that and just putting it anywhere they have broken markup that they don't want to fix or don't have the time to fix? |
| 09:40 | <MikeSmith> | the general approach gives them an easy out |
| 09:43 | <Stevef_> | mikesmith: ok so if the alt attribute was a long name such as generator-unable-to-provide-required-alt="" why would they use it over alt="" since both silence the validator? |
| 09:45 | <MikeSmith> | they wouldn't |
| 09:45 | <MikeSmith> | people wouldn't |
| 09:46 | <MikeSmith> | nobody is expected to manually put that into their markup |
| 09:46 | <MikeSmith> | it's solely intended for generators to add to img elements |
| 09:46 | <MikeSmith> | machines, not people |
| 09:47 | <Stevef_> | mikesmith: ok |
| 09:48 | <Stevef_> | mikesmith: so there should be conformance requirments about who can use it right? |
| 09:49 | <Stevef_> | mikesmith: under what circumstances |
| 09:53 | <Stevef_> | only for use in automated markup generators an document format conversion tools. Not for use in WYSIWYG editors etc |
| 09:57 | <MikeSmith> | Stevef_: yeah, that would be what I would restrict it to |
| 09:57 | <MikeSmith> | tools that do not require human intervention in order to generate the markup they generate |
| 09:58 | <MikeSmith> | they may be parts for some bigger system, like what the CP describes |
| 09:59 | <MikeSmith> | the author is working in a WYSIWG editor to create the part of the page/application/content they are directly responsible for |
| 09:59 | <MikeSmith> | then the system combines that manually authored content with machine-generated content to produce a page |
| 10:00 | <MikeSmith> | the author then wants to validate that completed page |
| 10:00 | <Stevef_> | then it sounds like a reasonable aproach, but it should be advised that its use must not be used as a reason not to provide downstream authors with a method to add alt text |
| 10:00 | <MikeSmith> | sure |
| 10:17 | <Stevef_> | mikesmith: so the current wording around the meta exception would need to be tightened up, "identifies one of the software packages used to generate the document. This value must not be used on hand-authored pages." as presumably hand authored pages don't make the cut and 'software packages' could mean anything |
| 10:18 | <MikeSmith> | Stevef_: I think if we did generator-unable-to-provide-required-alt it would mean removing some of that language completely |
| 10:20 | <Stevef_> | sure |
| 10:40 | <MikeSmith> | It's depressing to hear dude already saying "I’ll be objecting to this proposed relaxed attribute" at this point in the discussion about Ted's CP |
| 11:25 | <hsivonen> | MikeSmith: It's also depressing but it's possible to correctly guess who the dude is. |
| 11:25 | <MikeSmith> | heh |
| 11:30 | <annevk> | public-html is fun |
| 11:30 | <annevk> | "I respect the fact that Ted worked on this in good faith, and under the desire to make things better." hard to not read that as "fuck you" |
| 11:35 | <annevk> | that we're still discussing <img alt> in 2012 is kinda weird too |
| 11:36 | <hsivonen> | annevk: because the chairing hasn't been like this http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0212.html |
| 11:37 | <annevk> | yeah, although I didn't quite like that he used "consensus" there |
| 11:39 | <annevk> | with <img alt> some kind of end user study would be interesting |
| 11:39 | <annevk> | the people I know that are blind never have much of a problem with me sharing an image every now and then |
| 11:42 | <annevk> | like if K shares a photo of the beach on Facebook, does a blind person feel left out because it lacks <img alt>? |
| 11:42 | <annevk> | and even if some do, is it reasonable to expect that situation to change? |
| 11:44 | <annevk> | it makes sense to have alt for <a href=/about><img src=/about.png alt="About us"></a> of course, but it's a lot harder with discussion platforms |
| 11:47 | <annevk> | http://www.spiegel.de/international/zeitgeist/no-copyright-law-the-real-reason-for-germany-s-industrial-expansion-a-710976.html is pretty interesting |
| 11:52 | <odinho> | annevk: Cool. |
| 11:56 | <AryehGregor> | Who's a good reviewer to ask for <https://bugzilla.mozilla.org/show_bug.cgi?id=751554>;? It will presumably be in MFBT. |
| 11:57 | <jgraham> | One in #developers? :p |
| 11:58 | <AryehGregor> | Sigh! |
| 11:58 | <AryehGregor> | I do that far too often. |
| 11:58 | <AryehGregor> | I need a better way to visually distinguish these two windows. |
| 11:58 | AryehGregor | grumbles |
| 11:58 | <AryehGregor> | (thanks for the correction) |
| 11:59 | jgraham | has no idea what MFBT is but has seen a bunch of blog posts from Jeff Walden that seem to be at a similar infrastructure level fwiw |
| 12:00 | <jgraham> | (I think) |
| 12:00 | <jgraham> | (althought it might have been someone else, and it might be totally unrelated) |
| 12:01 | <jgraham> | (so that was really a totally unhelpful comment) |
| 12:01 | <AryehGregor> | Yeah, I know he's a possible review candidate, just not sure if he's the best one -- I think I saw that he was away or something. |
| 12:02 | <jgraham> | I believe he is currently on a bicycle in the desert somewhere |
| 12:02 | <jgraham> | (or whatever they call the bit of the USA that isn't on the coasts) |
| 12:03 | <jgraham> | Reading planet.mozilla is great |
| 12:03 | <odinho> | jgraham: you corporate spy |
| 12:04 | <jgraham> | odinho: Not sure what I am spying on unless his bike trip is actually a secret mission :p |
| 12:05 | <odinho> | jgraham: Who's to say it isn't? :P |
| 12:11 | <AryehGregor> | jgraham, MFBT is Mozilla Framework Based on Templates, basically an attempt to write a library of easily-reusable generic macros/templates/etc. |
| 12:11 | <AryehGregor> | From scratch, with no dependencies on other Gecko stuff. |
| 12:12 | <AryehGregor> | I'm trying to get support for C++11's "enum class" feature, so I need to write a wrapper for old compiler versions. |
| 12:12 | <AryehGregor> | And that seems like the trendy place to put stuff like that these days. |
| 12:12 | <jgraham> | Ah. I think I remember seeing the acronym before because it is a rearragement of MTBF |
| 12:12 | <AryehGregor> | Yes, it's very confusing. |
| 12:12 | <AryehGregor> | Especially since I always misremember it as "Mozilla Template-Based Framework", which of course does abbreviate to MTBF. |
| 12:12 | <jgraham> | I would totally have called it Mozilla Template Based Framework |
| 12:12 | <jgraham> | heh |
| 12:13 | <AryehGregor> | Maybe they did originally, and it proved too confusing . . . |
| 12:13 | <jgraham> | Maybe they didn't want to set themselves up for the obvious jokes when it fails :) |
| 12:21 | <hsivonen> | AryehGregor: I believe it's easier to remember if you think of it as an abbreviation for Mozilla Friday Beer Time. |
| 12:25 | <AryehGregor> | jgraham, also, as someone who grew up in Manhattan, I agree that the non-coastal parts of the US qualify as desert. |
| 12:25 | <AryehGregor> | The outer boroughs of New York City are suburbs, and anything outside the city limits is countryside. |
| 12:26 | <AryehGregor> | (My wife grew up in Queens, and does not agree that it is the suburbs, but she's biased) |
| 12:56 | <annevk> | and you're not biased? lol |
| 13:37 | <sedovsek> | Hey. |
| 13:37 | <sedovsek> | Shorthand for 'background' property does not work if it includes background-size? |
| 15:50 | <garciawebdev> | how is your code? |
| 16:09 | <dglazkov> | good morning, Whatwg! |
| 16:10 | <Ms2ger> | Good day |
| 16:42 | <Hixie> | jgraham: here now if you still have a question |
| 16:43 | <Hixie> | jgraham: was the problem just that the spec doesn't cache the base url when it's specified as a relative url? |
| 17:04 | <Hixie> | hsivonen: alt="" indicates that the image is decorative and can (and should) be skipped when it comes to users whose primary experience of the page doesn't include images. |
| 17:05 | <Hixie> | hsivonen: a missing alt="" attribute indicates that the image doesn't have an alt attribute, which is either a mistake, or means that the image is key content but that the page generator couldn't provide alternative text |
| 17:05 | <Hixie> | hsivonen: treating them as equivalent is thus not reasonable |
| 17:45 | <Hixie> | it strikes me that maybe there shouldn't be a limit on how many, say, autocomplete=cc-csc fields a form has |
| 17:45 | <Hixie> | they'll all have to be autofilled with the same value, but that's ok |
| 17:45 | <Hixie> | authors already ask for e.g. the e-mail to be given twice to confirm it |
| 17:46 | <Hixie> | i don't really see why someone would ask for both a tel-local and a tel-local-prefix and tel-local-suffix, but maybe they have a radio button that controls what the input looks like or something... |
| 18:54 | <jgraham> | Hixie: The problem was that the spec doesn't cache the base URL at all |
| 18:54 | <jgraham> | It recomputes it every time that something is resolved |
| 18:55 | <jgraham> | Which doesn't seem to match browsers, at least to the extent that pushState doesn't seem to affect the base URI |
| 18:58 | <Ms2ger> | Is http://wiki.whatwg.org/wiki/StringEncoding something we should implement? |
| 19:00 | <jgraham> | Ms2ger: I thought people seemed quite happy about that API at least |
| 19:00 | <Hixie> | jgraham: k, didn't test that, good to know. can you file a bug / send e-mail? |
| 19:00 | <Ms2ger> | Won't complain about it, then |
| 19:01 | <Hixie> | it makes sense that base urls wouldn't be reresolved, after all, nothing else does :-) |
| 19:01 | <Hixie> | s/does/is/ |
| 19:02 | <jgraham> | Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18459 |
| 19:02 | <Hixie> | awesome, thanks |
| 19:05 | <Hixie> | hsivonen, hober: your input on http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0004.html would be helpful |
| 19:05 | <Hixie> | hsivonen, hober: since MikeSmith is implementing, i intend to get to this as soon as i'm done with autocomplete="" |
| 19:05 | <Hixie> | which may be later tday |
| 19:25 | <Hixie> | Stevef_: any chance i can convince you to use regular quoting style on the whatwg list? it's great that you're posting, and i'm really glad to see productive conversations going on, but your quoting style is going to make replying to all the e-mails somewhat complicated for me |
| 19:26 | <__doc__> | I'm interested to get drawing tablets to work with browsers and have some standard for that. Any idea how I can get that ball rolling? |
| 19:27 | <Hixie> | __doc__: best first step is to convince a browser vendor to add experimental support for such a feature, so we get implementation experience |
| 19:27 | __doc__ | nods |
| 19:27 | <Hixie> | see http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F |
| 19:27 | <Hixie> | lunch, bbl |
| 20:12 | <Yuhong> | Win8 just RTMed and ships with IE10: http://blogs.msdn.com/b/b8/archive/2012/08/01/releasing-windows-8-august-1-2012.aspx |
| 20:12 | <Yuhong> | And on CSS style modularization of HTML, remember the "HTML5" buzzword will not disappear overnight. |
| 20:33 | <__doc__> | and with wart shutting out competing browsers, a lot of emerging standards will yet again be held up by microsoft |
| 20:34 | <zewt> | does adams actually represent a real vendor? now he's declaring an objection in advance, without even pretending that he's interested in discussion, and I'm inclined to ignore him, heh |
| 20:36 | <Ms2ger> | Don't think so |
| 20:38 | <zewt> | he's saying he'll "object" and that we should "deal with it now", heh |
| 20:40 | <Ms2ger> | I read it |
| 22:34 | <zewt> | well, i'm inclined to ignore him, heh |
| 22:35 | <zewt> | though if somebody knows who he is it would be nice (if perhaps not useful) to know who it is that's behaving like that, heh |
| 22:41 | <jamesr_> | glenn adams? |
| 22:42 | <zewt> | yeah |
| 22:43 | <jamesr_> | my understanding is that he is (or is employeed by) a w3c member, so if he says "I OBJECT!" he has equal weight to any other member within the w3c |
| 22:43 | <jamesr_> | imo he's also more than a little bit of a nut at times, to the point where if somebody talks about something "glenn" did i have to ask "do you mean zewt or the crazy glenn?" |
| 22:43 | <zewt> | well, if he's speaking on behalf of someone, i'd just be interested in knowing, since he's (in my opinion) behaving very poorly |
| 22:44 | <zewt> | (now he appears to be preemptively objecting to anything that doesn't somehow magically combine blob-style access and WebSockets) |
| 22:44 | <jamesr_> | i don't know what his organizational relationship is with the w3c. it's not with any browser vendor |
| 22:45 | <gsnedders> | Works for Cox, though quite what Cox have to do with HTML is interestingly. |
| 22:45 | <gsnedders> | *interesting |
| 22:45 | <jamesr_> | http://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html lists him as working for Cox, and http://www.w3.org/Consortium/Member/List says Cox is a W3C member |
| 22:46 | <Hixie> | jamesr_: there's a difference in weight between members |
| 22:46 | <Hixie> | jamesr_: those who implement have more practical weight than those who don't :-) |
| 22:46 | <jamesr_> | he's also editor on a couple css specs (and i don't think he's gone crazy there) |
| 22:46 | <zewt> | all I can do is hope that in reality if the real players (eg. real-world browser vendors) like it, an objection from someone like that won't actually have much effect |
| 22:47 | <smus> | someone mentioned that <img srcset> works in Safari on iOS 6. I can't get it to work using http://smus.com/m/srcset/ (on any browser) |
| 22:47 | <zewt> | (not that i wouldn't discuss it if he was making an interesting case, but all he's doing is derailing the hell out of the thread) |
| 22:47 | <jamesr_> | i think he's a known entity to most browser devs, but it depends on how much they care about w3c process and whatnot. he's definitely gone nuts before in a few places and i think been mostly ignored |
| 22:48 | <jamesr_> | Hixie, he can be a pain in the butt still, especially for editors/specs who are stuck with more w3c |
| 22:49 | <Hixie> | i don't see how he can be a pain unless people voluntarily opt-in to the bureaucratic process |
| 22:50 | <zewt> | Hixie: that's why i'm carefully opting-out and ignoring his threat :) |
| 22:50 | <Hixie> | and people who opt-in to that process are doing so of their own free will, so they deserve what they get |
| 22:50 | <Hixie> | zewt: indeed |
| 22:50 | <zewt> | i'll stick to the technical discussion and leave it to the politicians (so to speak) to deal with any w3c process crap later |
| 22:50 | <Hixie> | ok anyone see anything wrong in the new autocomplete section? |
| 22:51 | <paul_irish> | link? |
| 22:51 | <zewt> | (doing a read through) |
| 22:52 | <Hixie> | paul_irish: http://www.whatwg.org/specs/web-apps/current-work/#autofilling-form-controls:-the-autocomplete-attribute |
| 22:52 | <Hixie> | (sorry, not in multipage version yet) |
| 22:52 | <paul_irish> | thx |
| 22:53 | <zewt> | are locality and region intentionally vague for different regions? |
| 22:54 | <zewt> | i remember having to ship USPS (iirc) to Korea, and it was a 45 minute ordeal trying to split it apart into its components, since they had separate form fields for each and I didn't know what was what |
| 22:55 | <Hixie> | they're hte terms vCard uses |
| 22:55 | <zewt> | for horror's sake, that address (minus street numbers) was: Mcity tower 12346, 123 Changhang-dong, Ilsandong-gu, Koyang-si, Kyonggi-do, 410-380, Korea |
| 22:55 | <Hixie> | yikes |
| 22:55 | <zewt> | indeed |
| 22:55 | <Hixie> | yeah, having fields for address is pretty much bogus, but that's the way people do it, so... |
| 22:56 | <zewt> | apparently those suffixes are roughly analogous to city, state, province, etc |
| 22:56 | <Hixie> | i tried to provide generic fields where possible (name, e.g.) |
| 22:58 | <gavinc> | Hixie: I don't think cc-name makes a great deal of sense broken down, was there research on that? As far as I'm aware payment systems tend to simply take full name |
| 22:58 | <gavinc> | sorry, the cc-name breakdown |
| 23:04 | <Hixie> | gavinc: i added those because http://wiki.whatwg.org/wiki/Autocomplete_Types had them, but will investigate further... |
| 23:05 | <Hixie> | https://www.teleconference.att.com/resv/help/My_Profile/Credit_Cards/Add_a_Credit_Card.htm suggests at least some forms do have them separated |
| 23:06 | <gavinc> | gah, okay, I buy it now, but still gah |
| 23:07 | <Hixie> | oh i'm with you 100% |
| 23:07 | <Hixie> | the regular name fields being split out is just as ridiculous |
| 23:07 | <Hixie> | many people don't have more than one name |
| 23:07 | <gavinc> | Yeah, but I get WHY people do it |
| 23:07 | <gavinc> | for the cc... I mean, the payment gateways don't |
| 23:08 | <gavinc> | and the magstrip doesn't encode it |
| 23:08 | <gavinc> | so that's just really bad form design |
| 23:09 | <zewt> | the most awesome part is how it totally screws pasting in info |
| 23:09 | <gavinc> | I was thinking the most awesome part being that my wife couldn't fill in the form ;) |
| 23:11 | <Hixie> | plenty of people have that problem |
| 23:11 | <Hixie> | e.g. required phone number fields for people with no phones (e.g. me) |
| 23:11 | <Hixie> | sex fields that only accept "male" and "female" |
| 23:11 | <Hixie> | name fields that require a first and last name |
| 23:12 | <Hixie> | address fields for addresses like the one zewt pasted in earlier |
| 23:12 | <zewt> | heh |
| 23:12 | <zewt> | my work just had to buy a cheapo cellphone |
| 23:12 | <zewt> | because we need to do facebook dev, and there's no way to validate a FB account for development except a cellphone |
| 23:13 | <zewt> | (landlines are out, since it assumes you can receive an SMS) |
| 23:15 | <gavinc> | Not only that but not all cell phones work |
| 23:16 | <zewt> | also fun was while I was living in MA, anything sent USPS had to have the 9-digit zip code, or be delayed or lost |
| 23:16 | <zewt> | ... and of course, lots of forms limit zip code entry to 5 digits |
| 23:17 | <zewt> | and (if you can believe it) some of them would accept 9 digits, then they'd only use 5 |
| 23:17 | <zewt> | (often intentionally, eg. handwritten shipping slips, which means some idiot went "why is this guy giving me 9 digits? i'm going to save ink and only write out 5!") |
| 23:18 | <zewt> | humanity is stunningly innovative in finding new ways to screw up in stupid ways :) |
| 23:20 | <gavinc> | Mmm, but if the auto fill fields are specified as broken out for ccname aren't we going to be asking browser vendors to make UIs that some how have to divide up the name that for a CC really can't be? |
| 23:20 | <gavinc> | wouldn't it in fact be BETTER if auto fill didn't work on pages where the cc name is broken up? |
| 23:21 | <Hixie> | i'm presuming the UI would just be slurping data from other forms |
| 23:21 | <gavinc> | LastPass and OnePassword are likely better examples for credit card info |
| 23:22 | <zewt> | i'd think that cc billing name *has* to be a single form entry |
| 23:22 | <zewt> | since you want to enter the name exactly as it is on the card, and that can eg. include or not include a middle initial |
| 23:22 | <Hixie> | chrome already tries to autofill credit card info for me, and i never told it my info other than by filling in another form... |
| 23:23 | <zewt> | Hixie: is it expected that some of these labels would only actually be used to say "don't remember this field at all" (eg. cc-csc)? |
| 23:23 | <zewt> | (and probably in most sane cases cc-number too) |
| 23:24 | <zewt> | (in terms of what browsers would do with it, I mean) |
| 23:29 | <Hixie> | why would you not remember cc-csc? |
| 23:29 | <zewt> | isn't the whole point of those that they're never actually stored anywhere |
| 23:30 | <Hixie> | they're stored on my card |
| 23:30 | <Hixie> | why can't they be stored in my (more secure) browser? |
| 23:30 | <zewt> | but not in retail databases, etc |
| 23:30 | <Hixie> | nobody is saying to store it in retail databases, sure |
| 23:31 | <Hixie> | we're talking about browsers here, not retail databases |
| 23:31 | <zewt> | from what i understand, it's meant as an extra check that you actually have the card ... for example, so it's harder to use a cc# if you steal someone's history DB from their browser |
| 23:31 | <zewt> | browsers are much more vulnerable (in the typical case) than retail databases--typical users get viruses on a daily basis, and no typical user is going to password-lock their browser |
| 23:32 | <Hixie> | i am happy to run the risk that someone will steal my browser for the convenience of not having to type in this damn number over and over |
| 23:32 | <zewt> | (everyone who does "mom's computer support" knows how often those things happen, heh) |
| 23:32 | <Hixie> | (my laptop is a hell of a lot more secure than my wallet) |
| 23:32 | <zewt> | Hixie: that's fine for you; it'd be a very seriously bad idea for more typical users |
| 23:33 | <Hixie> | well they can have it not stored if they want |
| 23:33 | <zewt> | i mean, if browsers want to have an "i know what I'm doing, so store this", fine, I just don't think it'd be sane at all for most users |
| 23:45 | <zewt> | Hixie: minor: for postal-code, maybe use a 9-digit zip as the example instead of 5 |
| 23:46 | <Hixie> | if you can find me tim's 9-digit code, i'll get all over that :-) |
| 23:47 | <zewt> | who cares what tim's is? heh |
| 23:47 | <zewt> | oh yeah. credit card type |
| 23:47 | <zewt> | (visa, mastercard) |
| 23:48 | <zewt> | suppose that's usually a dropdown and not a text, so maybe it doesn't need help |
| 23:48 | <Hixie> | that's already there |
| 23:48 | <Hixie> | it's the first digit of the cc-number field |
| 23:48 | <zewt> | sure, but lots of sites ask for it separately anyway |
| 23:49 | <Hixie> | true, inexplicably |
| 23:49 | <Hixie> | not sure what to do about it |
| 23:49 | <zewt> | well, it's explainable, it's just not for a good reason :) |
| 23:49 | <Hixie> | the values are probably difficult to distinguish heuristically |
| 23:49 | <zewt> | (namely, incompetence) |
| 23:49 | <Hixie> | what's the reason? |
| 23:49 | <Hixie> | i mean, what do they do with it? |
| 23:49 | <zewt> | no idea, never written a payment service |
| 23:50 | <Hixie> | heh |
| 23:50 | <zewt> | (and I might not know if I had, since as you said it's redundant) |
| 23:50 | <gavinc> | It is possible to not be able to accept some CC types |
| 23:50 | <gavinc> | also to use diffrent payment gateways depending on type |
| 23:52 | <zewt> | are the values that difficult? there are maybe under a dozen values (at least commonly used in the US) |
| 23:52 | <zewt> | er, under half a dozen |
| 23:53 | <gavinc> | Oh, no |
| 23:53 | <gavinc> | Easy as heck |
| 23:53 | <zewt> | (asking because I'd expect it to be easy) |
| 23:53 | <gavinc> | BUT by having two fields (at least this was on POS) you can do a better job of checking if the entry of CC number worked correctly |
| 23:53 | <gavinc> | if someone says the type is this, and the number is that... |
| 23:54 | <Hixie> | it's literally just a number lookup: http://en.wikipedia.org/wiki/Bank_card_number |
| 23:54 | <zewt> | cc#'s have a validation digit anyway, right? |
| 23:54 | <gavinc> | I'm not claiming it's rational :P |
| 23:54 | <zewt> | Hixie: i'm not saying sites should do it, just that they do :) |
| 23:54 | <Hixie> | yeah, cc's have built-in check codes, see same wikipedia page |
| 23:54 | <Hixie> | :-) |
| 23:54 | <zewt> | (and there are a lot of values in this autocomplete feature that seem to be there based on that criteria :) |
| 23:54 | <gavinc> | Yeah, it's just mod 10 |
| 23:56 | <zewt> | if the autocomplete spec seemed to be trying to omit things people shouldn't be doing, to try to discourage them from doing it, then yeah it might make sense to omit credit card type too |
| 23:56 | <zewt> | doesn't seem to be your goal, though... |
| 23:56 | <Hixie> | the problem with credit card type is that nobody's done the research to see if the values are heuristically recognisable, nothing else |
| 23:57 | <Hixie> | i have no objection to adding it if it is actually implementable |
| 23:57 | <zewt> | well, the heuristic matching would probably have to be on the text of the option, not the @value |
| 23:58 | <Hixie> | most pages i've seen use images |
| 23:58 | <Hixie> | (anecdotally) |
| 23:59 | <gavinc> | anecdotally, lasspass and 1Password don't store type |