| 00:40 | <Hixie> | wow i had no idea that you could mail draft-abarth-origin⊙tio |
| 00:40 | <Hixie> | that's pretty neat |
| 00:51 | <JonathanNeal> | In HTML, when you have a label and an input, what would you call that pairing. I ask because I want to wrap it in a div and give it a classname that describes the content. |
| 00:52 | <JonathanNeal> | I think it's a control, right? |
| 01:33 | <TabAtkins> | Labelled input? |
| 03:02 | <JonathanNeal> | So, am I keeping up with the latest WHATWG changes @ http://www.iecss.com/whatwg.css ? |
| 03:13 | <karlcow> | jgraham: definition of IAU http://en.wikipedia.org/wiki/IAU_definition_of_planet#Final_definition |
| 03:13 | <MikeSmith> | "Beaver Taste Great With Mustard" |
| 03:13 | <MikeSmith> | now that's good |
| 03:13 | <MikeSmith> | give us more of that kind of stuff please |
| 03:13 | <karlcow> | including http://www.iau.org/public_press/news/release/iau0601/q_answers/ |
| 03:14 | <karlcow> | Hmm beaver! |
| 03:15 | <karlcow> | eating beaver like a mountain man |
| 03:25 | <othermaciej> | Hixie: your description of which <a> elements on reddit are buttons vs. links makes me doubt my sanity |
| 03:34 | <Hixie> | othermaciej: it's just a matter of what they look like |
| 03:34 | <othermaciej> | really? |
| 03:34 | <othermaciej> | are the semantics of all controls defined by their appearance rather than behavior, or only links and buttons? |
| 03:35 | <Hixie> | i don't understand the question |
| 03:35 | <Hixie> | the point of ATs is to expose what the controls look like to non-AT users |
| 03:35 | <othermaciej> | all right, let me give a concrete example |
| 03:35 | <othermaciej> | look at this control: |
| 03:35 | <othermaciej> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23mystery%20%7B%0A%20%20%20%20background%3A%20white%20url(http%3A%2F%2Fwww.reddit.com%2Fstatic%2Fgradient-button.png)%20repeat-x%20scroll%200%25%2050%25%3B%0A%20%20%20%20border%3A%201px%20solid%20%23C4DBF1%3B%0A%20%20%20%20display%3A%20block%3B%0A%20%20%20%20font-size%3A%20150%25%3B%0A%20%20%20%20font-weight%3A%20bold%3B%0A%20%20%20%20height%3A%2029px%3B%0A%20%20%2 |
| 03:35 | <othermaciej> | tter-spacing%3A%20-1px%3B%0A%20%20%20%20line-height%3A%2029px%3B%0A%20%20%20%20position%3A%20relative%3B%0A%20%20%20%20text-align%3A%20center%3B%0A%20%20%20%20margin%3A%090px%3B%0A%20%20%20%20padding%3A%200px%3B%0A%7D%0A%3C%2Fstyle%3E%0A%0A%3Cinput%20id%3Dmystery%20type%3Dtext%20value%3Dmystery%3E%0A |
| 03:35 | <othermaciej> | I guess I should shorten that, hold on a sec |
| 03:35 | <Hixie> | and the point of ARIA is to enable that to happen when the browser can't figure it out |
| 03:35 | <othermaciej> | http://bit.ly/cK5Cfo |
| 03:35 | <Hixie> | you can use hte "save" link |
| 03:36 | <Hixie> | to get a shorter URL |
| 03:36 | <othermaciej> | what are the semantics of that control? |
| 03:36 | <othermaciej> | is that control semantically a button? |
| 03:36 | <Hixie> | i don't know what you mean by "semantic" in this context |
| 03:37 | <othermaciej> | I am refering to whatever you meant when you wrote "Authors must not use elements, attributes, or attribute values for purposes other than their appropriate intended semantic purpose." |
| 03:37 | <Hixie> | the intended semantic purpose of <input type=text> is a text control |
| 03:37 | <Hixie> | is that the purpose to which you are putting it here? |
| 03:37 | <othermaciej> | am I correctly using it for the intended semantic purpose? |
| 03:38 | <othermaciej> | or am I abusing it for the semantic purpose of a button? |
| 03:38 | <Hixie> | you are using it to try to prove a point in an argument, so no, it's no the appropriate intended semantic purpose |
| 03:38 | <Hixie> | :-P |
| 03:38 | <othermaciej> | you seemed to argue that a link with that styling has the semantics of a button, even if it has the behavior of a link |
| 03:38 | <othermaciej> | whereas something that looks like a link but has the behavior of a button is a link |
| 03:38 | <othermaciej> | I am wondering how far that extends |
| 03:39 | <othermaciej> | my understanding of control semantics is that it's tied to the behavior, not the appearance |
| 03:39 | <Hixie> | not sure what you mean by "behaviour of a link" vs "behaviour of a button" |
| 03:39 | <othermaciej> | and I was mighty confused to see you argue otherwise |
| 03:39 | <othermaciej> | are you saying the only semantic difference between links and buttons is their visual appearance? |
| 03:39 | <Hixie> | isn't it? |
| 03:40 | <othermaciej> | my understanding is that the semantics of a link are that it links to something |
| 03:40 | <othermaciej> | and the semantics of a button are that it actuates a command |
| 03:40 | <othermaciej> | regardless of what either looks like |
| 03:40 | <othermaciej> | and that properly using an <a> element for a link has consequences such as appropriate cursor and status bar behavior on hover, being recognized as indexable by search engines, etc |
| 03:41 | <Hixie> | isn't "link to something" a command? |
| 03:41 | <othermaciej> | it's a specific subset of commands |
| 03:41 | <othermaciej> | there are clearly commands that are not a "link to something" |
| 03:41 | <othermaciej> | (such as the command performed by the reddit submit button) |
| 03:42 | <othermaciej> | er, the reddit share button |
| 03:42 | <othermaciej> | similarly, "toggle" is a form of command, but that doesn't mean buttons and checkboxes are interchangeable other than appearance |
| 03:42 | <Hixie> | i think i could convincingly argue this about 5 different ways if i tried |
| 03:42 | <Hixie> | i don't think any of them would help us in the context of ATs and ARIA |
| 03:43 | <othermaciej> | I'm just trying to understand what it means to forbid using a link as a button |
| 03:44 | <othermaciej> | your argument seems to be based on the premise that doing that should be disallowed, but your examples of what does or does not constitute using a link as a button did not help my comprehension |
| 03:45 | <Hixie> | ok forget what i said about reddit. here's a better way to think about it based on what you said earlier. |
| 03:45 | <othermaciej> | and made me doubt my understanding of the requirement, ""Authors must not use elements, attributes, or attribute values for purposes other than their appropriate intended semantic purpose."" |
| 03:45 | <Hixie> | a link is something that provides the user with a URL |
| 03:45 | <othermaciej> | I would agree with that definition |
| 03:45 | <othermaciej> | (by that definition, "Submit a link" on reddit would be a link, but "share" would not) |
| 03:45 | <Hixie> | a button is something that provides the user with the option to activate something defined by the author at a user-selected time |
| 03:46 | <othermaciej> | and by that definition, "share" would be a button but you could also argue that all links (at least in the control sense) are also buttons |
| 03:46 | <Hixie> | so on reddit, the arrows and "share" should be buttons, and "submit a link" should be a link |
| 03:46 | <othermaciej> | I agree |
| 03:47 | <Hixie> | so using <a> for "share" is wrong |
| 03:47 | <othermaciej> | also agree |
| 03:47 | <Hixie> | ok |
| 03:48 | <othermaciej> | so looking at the specific example of "share", I think the point Steve and Sam were calling attention to was: |
| 03:49 | <othermaciej> | -> the spec makes it a validator error to put rule="button" on that <a> element, because it would be making an <a> element act as a button, contrary to its semantics |
| 03:49 | <Hixie> | the spec makes using <a> a validator error too, albeit one that few validators will ever be able to report in the coming few years |
| 03:49 | <othermaciej> | -> the spec does not make it a validator error to use href="#" onclick="..." on that <a> element, even though almost the sole use of that markup is to make an <a> element act like a button |
| 03:50 | <Hixie> | my point is that it does |
| 03:50 | <othermaciej> | (and similarly for href="javascript:...", although that's not used in this particular case) |
| 03:50 | <Hixie> | the spec does disallow that |
| 03:50 | <othermaciej> | it disallows the concept with a non-machine-checkable requirement, but does not make the syntax an error |
| 03:50 | <othermaciej> | however, it does make the syntax <a role="button"> an error |
| 03:50 | <Hixie> | right, role="" is a godsend here |
| 03:50 | <othermaciej> | with a machine-checkable rule |
| 03:51 | <Hixie> | it finally allows us an opportunity to catch this using a syntax error |
| 03:51 | <Hixie> | there are lots of things that cannot be caught using syntax errors |
| 03:51 | <Hixie> | they are no less errors |
| 03:51 | <karlcow> | othermaciej: the issue is in part what is the link. Is it a POST or a GET. http://bitworking.org/news/I_m_sorry__I_can_t_kiss_it_and_make_it_better_ |
| 03:51 | <othermaciej> | in principle, a link with href="#" onclick="..." or href="javascript:..." could be a syntax error, unless that syntax serves a valid use case that cannot be achieved in any other way |
| 03:51 | <Hixie> | and when we can catch them we try to do so |
| 03:51 | <Hixie> | indeed |
| 03:52 | <Hixie> | (unfortunately, there are such use cases) |
| 03:52 | <othermaciej> | ok, so explaining what those are would help resolve the apparent contradiction |
| 03:52 | <Hixie> | the use cases? |
| 03:52 | <othermaciej> | since a naiive observer such as myself reading the change proposal might be unaware of those use cases |
| 03:52 | <Hixie> | href="javascript:"'s use case is exposing bookmarklets |
| 03:53 | <karlcow> | http://natbat.net/2009/Jun/10/styling-buttons-as-links/ |
| 03:53 | <othermaciej> | good point |
| 03:53 | <othermaciej> | (my suggestion would be to cite these in your Change Proposal and/or in resolving SteveF's bugs when you get around to that) |
| 03:53 | <Hixie> | onclick="..."'s use case is for such things as click-tracking or general user interaction, or making links that are both functional in "AJAX" and static scenarios |
| 03:54 | <Hixie> | i don't understand why they are relevant to the change proposal |
| 03:54 | <othermaciej> | right, but you would never use href="#" [sic] for a click-tracked link that is supposed to work in both static and AJAX scenarios |
| 03:54 | <karlcow> | http://jontangerine.com/silo/html/button/ |
| 03:54 | <Hixie> | making href="#" non-conforming might make sense |
| 03:55 | <Hixie> | it's kind of a weirdly specific case to disallow |
| 03:55 | <Hixie> | i mean i don't see much point linking to the same page, but why would we disallow it? |
| 03:55 | <Hixie> | it's just a relative URL... |
| 03:55 | <othermaciej> | I think Steve's point was that href="#" onclick="..." is exclusively used to make <a> elements act like buttons and has no valid use case |
| 03:56 | <othermaciej> | I agree that it would be an awfully specific thing to disallow, though one could claim the same of <a role="button"> |
| 03:56 | <othermaciej> | anyway |
| 03:56 | <othermaciej> | I think those were the questions being asked |
| 03:56 | <othermaciej> | feel free to respond as you see fit |
| 03:56 | <othermaciej> | I should be going |
| 03:56 | <Hixie> | role="button" isn't specifically disallowed |
| 03:56 | <Hixie> | it's just not included in the list of things that are allowed |
| 03:57 | <othermaciej> | rather, it's not specifically allowed |
| 03:57 | <othermaciej> | anyway |
| 03:57 | <Hixie> | that's the opposite argument :-) |
| 03:57 | <othermaciej> | I don't want to argue the point further, you have explained these matters enough that I feel I understand them, but you may want to explain the above points on the list for the benefit of others |
| 03:58 | <othermaciej> | I hope that my confusion was understandable and I expect others may share it |
| 03:58 | <othermaciej> | thanks for the explanation |
| 03:58 | <Hixie> | the only others i care about here are sam and paul, frankly |
| 03:59 | <Hixie> | and last time i included counter-arguments in a change proposal i was told it was a waste of time |
| 03:59 | <Hixie> | and indeed it had no effect |
| 03:59 | <Hixie> | so i'm at a loss as to how to include this in a useful manner |
| 04:00 | <othermaciej> | I think they (and perhaps Steve) would likely benefit from an explanation of these points, even if it is just in an ordinary email to the list |
| 04:00 | <othermaciej> | explaining to Steve is useful because if he chooses to withdraw his proposal or agrees to some compromise (e.g. disallowing href="#" onclick="..." and/or explaining in more detail that buttons shouldn't be abused as links and explaining the valid use cases for <a href="javascript:">), that ends the process without Sam or Paul's opinion being relevant |
| 04:34 | <MikeSmith> | strawman attempt at a concise definition of what the term "the Web platform" means: |
| 04:34 | <MikeSmith> | [[ |
| 04:34 | <MikeSmith> | "a client-side (browser-side) runtime/processing environment for |
| 04:34 | <MikeSmith> | Web applications and Web documents that are built using HTML, |
| 04:34 | <MikeSmith> | CSS, Javascript and a couple of other core-standard formats, and |
| 04:34 | <MikeSmith> | that are addressed and transmitted using HTTP, URIs and a couple |
| 04:34 | <MikeSmith> | of other core-standard protocols" |
| 04:34 | <MikeSmith> | ]] |
| 04:34 | <MikeSmith> | comments, suggestions, refinements, please |
| 04:35 | <wirepair> | 'couple of other' used 2x ... |
| 04:36 | <roc> | the list of relevant standards is much longer than that |
| 04:36 | <wirepair> | seems lil vaguish |
| 04:41 | <MikeSmith> | it's intended to be minimal |
| 04:42 | <MikeSmith> | not to be an exhaustive list |
| 04:43 | <roc> | then just say "... and other standard formats" |
| 04:45 | <MikeSmith> | OK |
| 06:39 | <MikeSmith> | oh, issue 56 is _my_ fault |
| 06:39 | <MikeSmith> | [[ |
| 06:39 | <MikeSmith> | ISSUE-56 was raised in error by Michael(tm) Smith based on a |
| 06:39 | <MikeSmith> | misunderstanding of Roy's messages to the working group. |
| 06:39 | <MikeSmith> | ]] |
| 06:42 | <MikeSmith> | fwiw, there was never any misunderstanding |
| 06:45 | <othermaciej> | wait, what? |
| 06:45 | <MikeSmith> | not on my part at least |
| 06:45 | <MikeSmith> | I'm not even sure that I was the one who raised that issue initially, though I ended up becoming the owner for it |
| 06:46 | <MikeSmith> | Adam's change proposal |
| 06:46 | <MikeSmith> | which change proposal I personally happen completely agree with, fwiw |
| 06:47 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html |
| 07:06 | <othermaciej> | MikeSmithX: it's starting to seem like a better approach than either of the other proposals |
| 07:11 | <boblet> | “We might actually be able to process hyperlinks interoperably, leading to joy and happiness… purveyors of whisky might go out of business.” |
| 07:11 | <boblet> | lol |
| 07:15 | <MikeSmith> | I was going to say, the lesson for me here is to not raise issues on behalf of anybody else |
| 07:15 | <MikeSmith> | especially when I don't personally agree it's an issue |
| 07:16 | <MikeSmith> | but I actually learned that lesson quite a while ago |
| 07:16 | <MikeSmith> | which is why I don't do it any more |
| 07:16 | <othermaciej> | fortunately, the new process encourages people to raise their own issues, or at least provide issue text |
| 07:17 | <MikeSmith> | yeah |
| 07:18 | <othermaciej> | anyway, I am glad Adam posted that Change Proposal, even if he partly meant it as a reductio ad absurdum of the process |
| 07:18 | <MikeSmith> | yeah |
| 07:18 | <MikeSmith> | the summary is a very good and succinct statement of the fact that this is a non-problem |
| 07:19 | <MikeSmith> | and arguably always has been |
| 07:20 | <othermaciej> | well, he's actually arguing for a change relative to the way the spec is currently |
| 07:20 | <othermaciej> | I think once I read his proposal closer I might conclude it lacks sufficient detail |
| 07:21 | <othermaciej> | though that could be fixed by linking to http://www.w3.org/html/wg/href/draft for instance |
| 07:23 | <MikeSmith> | othermaciej: well, let me put it this way: I don't think there is any risk of implementor confusion about this part of the spec, nor has there ever been |
| 07:23 | <MikeSmith> | I agree with what Adam writes about adding text for clarification, but I don't think it's all that necessary to add it |
| 07:24 | <MikeSmith> | except to appease those who have objected to the terminology |
| 07:24 | <othermaciej> | I don't think implementors would be confused by the different use of the word URL |
| 07:25 | <othermaciej> | so far none of them have been |
| 07:25 | <othermaciej> | I don't know about other possible audiences for the spec |
| 07:26 | <MikeSmith> | I don't think even a casual reader would be confused by it |
| 07:26 | <othermaciej> | I think the factoring issue (where should the processing to convert what occurs in an href attribute to a URI/IRI/whatever be defined, in HTML5 or in IRI or in some third document) is somewhat orthogonal to the terminology issue |
| 07:26 | <MikeSmith> | I don't think _anybody_ would really be confused by it |
| 07:26 | <othermaciej> | however, so far no one else has stepped up to the plate to write a viable spec for this |
| 07:27 | <MikeSmith> | yeah, the factoring issue is certainly orthogonal |
| 07:27 | <MikeSmith> | and we did have come half-hearted previous attempts at writing a separate spec |
| 07:27 | <othermaciej> | ISSUE-56 is primarily about where the relevant spec text goes, not the terminology, that was ISSUE-72 which is already closed (by timeout) |
| 07:28 | <MikeSmith> | the other thing is, the term "URL" is long-deprecated by the purists anyway |
| 07:28 | <MikeSmith> | they have abandoned it |
| 07:29 | <MikeSmith> | so it's always seemed to me to be somewhat ironic to see an objection to how it's been used here |
| 07:29 | <MikeSmith> | anyway, I think this is one of those issues where you could count the number of people who feel strongly about it on one hand |
| 07:30 | <MikeSmith> | even if you were missing fingers |
| 07:30 | <MikeSmith> | not that the number of people objecting strongly is the only measure of whether it's important or not |
| 07:31 | <othermaciej> | I will say this - I personally care that the proper interoperable processing rules for browsers are spec'd *some*where |
| 07:32 | <othermaciej> | I don't care that much where that place is |
| 07:32 | <othermaciej> | I don't think the people with specific preferences in that regard should get unlimited time to produce something usable though |
| 07:33 | <MikeSmith> | yeah |
| 07:42 | <hsivonen> | jgraham: ISO makes some of its spec available as .pdf.zip, which is just unbelievable user-hostile compared to posting .pdf with flate streams inside |
| 07:44 | <hsivonen> | jgraham: and you can get a useful reference by linking to a know-good rev of the wikipedia article |
| 07:50 | <hsivonen> | MikeSmith: for defining the Open Web Platform, I suggest the following definition: |
| 07:51 | <hsivonen> | MikeSmith: give a feature one point for support in each of Gecko, WebKit, Presto and Trident in their latest versions |
| 07:51 | <hsivonen> | (so each feature gets a score from 0 to 4) |
| 07:51 | <hsivonen> | features that score 3 or 4 are part of the Platform |
| 08:03 | <MikeSmith> | hsivonen: that is a great definition for us to use with each other |
| 08:03 | <MikeSmith> | but it's one that does not go over quite as well with others |
| 08:03 | <MikeSmith> | e.g., with non-implementors |
| 08:22 | <hsivonen> | hooray to abarth_ for the Change Proposal for ISSUE-56 |
| 08:22 | <abarth_> | hi hsivonen |
| 08:22 | <abarth_> | i should have been a spec lawyer |
| 08:23 | <othermaciej> | I appreciate that abarth_ posted it as well, even though part of it was vaguely trying to make fun of me |
| 08:23 | <othermaciej> | they should totally have spec law school |
| 08:23 | <othermaciej> | but then you'd have to pass the spec bar exam to be allowed to practice as a spec lawyer |
| 08:24 | <abarth_> | the bit about whisky purveyors? |
| 08:24 | <abarth_> | :) |
| 08:24 | <othermaciej> | no, my borderline alcoholism is fair game |
| 08:25 | <othermaciej> | and may well go beyond borderline before HTML5 is done |
| 08:30 | <zcorpan_> | if we disallow href="#", all we'll achieve is to annoy authors and make them use href="#i-hate-html5" instead |
| 08:32 | <othermaciej> | I personally think trying to enforce semantics via syntax errors is an ill-conceived project |
| 08:32 | <zcorpan_> | i agree |
| 08:33 | <zcorpan_> | also, the world doesn't fall apart if authors use <a role=button> |
| 08:34 | <MikeSmith> | abarth_: hey man |
| 08:34 | <MikeSmith> | sorry for any vehemence in my replies on public-html |
| 08:35 | <abarth_> | MikeSmith: hi |
| 08:35 | <zcorpan_> | Hixie: "The current text satisfies the above edit instructions (as I'm sure Tab intended)." i thought hsivonen wrote the counter proposal |
| 08:35 | <MikeSmith> | abarth_: I have to carefully preserve the fiction that I actually know what I'm doing |
| 08:35 | <abarth_> | haha :) |
| 08:35 | <MikeSmith> | :) |
| 08:36 | <abarth_> | MikeSmith: i'm trying to read public-html after filter out all the emotion |
| 08:36 | <MikeSmith> | I find that drugs help |
| 08:36 | <abarth_> | so, i think i missed any vehemence |
| 08:41 | <Hixie> | zcorpan_: oops |
| 08:41 | <Hixie> | zcorpan_: oh well it's what happens because i ignore the From: line when reading e-mails! |
| 08:45 | <Hixie> | "the current text implies that HTML is super-easy, while XHTML is so hard that even the Working Group can't explain it" |
| 08:45 | <Hixie> | someone should propose a change proposal that makes it explicit that HTML is that hard |
| 08:45 | <Hixie> | since apparently julian doesn't think we've made that clear enough |
| 08:49 | <asmodai> | Hixie: hard/easy? In the context of writing a spec? |
| 08:50 | <Hixie> | er, s/HTML/XHTML/ in my above comment |
| 09:06 | <othermaciej> | to be fair, HTML is also hard in many ways! though not escaping rules in particular |
| 09:10 | <zcorpan_> | Q: What are the risks? |
| 09:10 | <zcorpan_> | A: We might actually be able to process hyperlinks interoperably, |
| 09:10 | <zcorpan_> | leading to joy and happiness. With so much joy in the work, purveyors |
| 09:10 | <zcorpan_> | of whisky might go out of business. |
| 09:10 | <zcorpan_> | LOL |
| 09:10 | <annevk> | call for consensus for XHR CR |
| 09:10 | <annevk> | never got this close before |
| 09:10 | <annevk> | jippiedieyay |
| 09:11 | <abarth> | zcorpan_: omg, typo... s/work/world/ |
| 09:11 | <annevk> | maybe it's more like jippydiyay |
| 09:12 | <annevk> | abarth, note that it's not just HTML that uses that kind of processing |
| 09:12 | <abarth> | ssh! |
| 09:12 | <annevk> | abarth, as you're probably aware, XMLHttpRequest, CSS, HTTP, etc. all use it |
| 09:12 | <annevk> | haha |
| 09:12 | <annevk> | but yeah, whatever |
| 09:16 | <othermaciej> | annevk: write some CR exit criteria please so I can support the CR transition in good consience |
| 09:20 | <Hixie> | annevk: you can crib the CR exit criteria from the whatwg charter if you like :-) |
| 09:32 | <MikeSmith> | what does the "from TFA" part in dudes message mean? |
| 09:42 | <annevk> | othermaciej, I plan to just use http://www.w3.org/TR/CSS21/#crec |
| 09:44 | <Hixie> | that's basicaly what the whatwg charter has |
| 09:44 | <Hixie> | (word for word) |
| 09:44 | <othermaciej> | annevk: it would be simpler IMO to just say there should be two implementations that pass every test case |
| 09:44 | hsivonen | hadn't realized CSS had a 6-month rule |
| 09:45 | <othermaciej> | then you don't have to define the scope of what is a "feature" |
| 09:45 | Hixie | agrees with othermaciej that that requirement is better -- require a comprehensive test suite and two fully compliant implementations |
| 09:45 | <slartsa> | hsivonen: what do you mean? |
| 09:46 | <othermaciej> | given the relatively small size of XHR, it would be silly to define different pieces of it as separate features, and a waste of time to debate which subsection levels constitute feature boundaries |
| 09:46 | <hsivonen> | http://www.w3.org/WAI/PF/HTML/track/actions/24 looks odd given PF's own statements |
| 09:46 | <othermaciej> | also it does not seem like a huge burden to expect two complete implementations |
| 09:46 | <hsivonen> | slartsa: I mean that 6 months from the start of CR has to pass even if the other criteria were met sooner |
| 09:47 | <slartsa> | now would that just be there to narrow possible errors? |
| 09:47 | <othermaciej> | annevk: those CR exit criteria also don't seem to say anything about the comprehensiveness of the test suite used to judge implementations of any given feature |
| 09:48 | <hsivonen> | slartsa: yeah, I just hadn't realized there was a 6-month rule |
| 09:48 | <annevk> | othermaciej, ok |
| 09:48 | <othermaciej> | also they effectively make all features potentially "at risk" |
| 09:48 | <annevk> | othermaciej, I wouldn't let it pass CR without two complete implementations and an extensive test suite, but maybe it is better to put that in writing indeed |
| 09:48 | <othermaciej> | which is explicitly disallowed by the W3C process |
| 09:49 | <othermaciej> | annevk: I would like to see that in writing, so there's no misunderstandings later with other WG members |
| 09:49 | <othermaciej> | you're not allowed to just say "any feature without two implementations will be dropped", you have to list specific features as being "at risk" if they don't meet the relevant criteria |
| 09:50 | <othermaciej> | at least that is my recollection |
| 09:50 | <othermaciej> | for XHR I am not sure any features should be "at risk" |
| 09:52 | <annevk> | no I agree |
| 09:53 | <annevk> | ok, I'll take it more serious :) |
| 09:54 | <Hixie> | othermaciej: the csswg discussed that long ago and basically decided that they would go back to LC often enough anyway since they were going to maintain the spec that if that became an issue, they'd just cycle again and list the at-risk parts (or just remove them) |
| 10:05 | <annevk> | TabAtkins, oh, it was a joke? you know, the CSS WG leaving px undefined would not be so surprising really :) |
| 10:12 | <hsivonen> | annevk: what was a joke? |
| 10:13 | <annevk> | http://twitter.com/fantasai/status/16181517781 |
| 10:13 | <annevk> | this WebM stuff is problematic |
| 10:13 | <annevk> | YouTube now works in Opera |
| 10:13 | <hsivonen> | annevk: that was too subtle for me to realize it was a joke |
| 10:14 | <hsivonen> | annevk: so what's the problem with WebM? |
| 10:14 | <hsivonen> | annevk: youtube harms your productivity? |
| 10:14 | <jgraham> | hsivonen: What will people complain about? |
| 10:14 | <annevk> | hsivonen, exactly, I might end up watching YouTube all day |
| 10:15 | <annevk> | not having Flash helped a lot, but then they found this workaround |
| 10:15 | <jgraham> | I mean for 10.50 we got _so_many_ people saying "why doesn't HTML5 video work in Opera" |
| 10:15 | <jgraham> | because we didn't support H.264 Youtube |
| 10:16 | <hsivonen> | Am I supposed to get a WebM-enabled Opera build from the "beta-stable" apt source? |
| 10:16 | <annevk> | should I read the 31 emails on "RE: Transferring File* to WebApps - redux"? |
| 10:16 | <annevk> | (I don't know the public sources for Opera distribution... I'm using the latest internal nightlies...) |
| 10:17 | <jgraham> | hsivonen: I think you have to look at the desktop team blog |
| 10:17 | <annevk> | well, from an internal URL; there doesn't seem to be a much of difference anymore between what I use and someone who doesn't work for Opera; which is pretty great |
| 10:17 | <hsivonen> | jgraham: :-( the repo is offering 10.53.6330 to me |
| 10:18 | <annevk> | yeah, we should set up something like Chrome does |
| 10:18 | <jgraham> | hsivonen: Yeah, I know, our update situation for dev builds really sucks |
| 10:18 | <gsnedders> | hsivonen: AFAIK beta still pushes stable for some raeson |
| 10:19 | <annevk> | in that thread someone mentions bondi |
| 10:19 | annevk | ran away |
| 10:36 | <Lachy> | annevk, the speech input proposal was linked to in a previous email. http://docs.google.com/View?id=dcfg79pz_5dhnp23f5 |
| 10:37 | <annevk> | oh wow that looks complex |
| 10:37 | <Lachy> | I'm not sure I get the whole purpose of it. It's been possible to use speech input with any form control for years, given a microphone and speech recognition software. |
| 10:40 | <annevk> | there must be something why that doesn't just work, but it's not explained very well |
| 10:41 | <Lachy> | ah, it describes utterrance="" and interpretation="" attributes that help with defining what speech commands are accepted |
| 10:49 | Hixie | tries to work out what faulkner's e-mail means... is he saying that when the WAI said we should have "strong semantics" or whatever it was that they were wrong? |
| 11:04 | <AryehGregor> | Am I the only one who dies a little inside whenever I see a line beginning with ">From" in an e-mail when it should be "From"? |
| 11:05 | <annevk> | http://www.w3.org/TR/xbl/ has no exit criteria? |
| 11:05 | annevk | is looking at prior art |
| 11:09 | <Hixie> | AryehGregor: you are not |
| 11:10 | <Hixie> | AryehGregor: i die even more when it's my own e-mails |
| 11:11 | <AryehGregor> | :( |
| 11:11 | <AryehGregor> | If only the guy who came up with mbox had heard of reversible escaping. |
| 11:12 | <AryehGregor> | "Specifying a grammar is useful for apps which have limited vocabulary, for e.g. commands, navigation within page, maps etc. Such applications would not work as well with free-form text input. @pattern can be used to restrict the allowed inputs, but regular expressions are less expressive than context-free grammars." That sounds extremely scary. |
| 11:13 | <workmad3> | wow, it's been a while since I came across a discussion involving context-free grammars :) |
| 11:14 | <workmad3> | now, if only I could remember what they are and what characterized them... |
| 11:15 | <AryehGregor> | Are context-free grammars exactly those that can be described in BNF, by any chance? Like regular expressions and regex? |
| 11:15 | AryehGregor | isn't sure. |
| 11:16 | <workmad3> | that's the problem :) |
| 11:18 | <AryehGregor> | Am I the only one who finds back/forward in Chrome dev channel is sometimes incredibly flaky? |
| 11:20 | <AryehGregor> | It will regularly forget items in the history, and just now it completely made up a history entry. A page I visited once and bookmarked, months ago, replaced the entire history for the tab. |
| 11:20 | <AryehGregor> | I would report it, but haven't tried to reproduce it consistently . . . |
| 11:28 | <oal> | Is there a good article that describes WebSockets, and what it's all about? |
| 11:29 | <Hixie> | the spec has some intro material that might help |
| 11:30 | <oal> | Over at w3.org? |
| 11:30 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#introduction-7 |
| 11:30 | <oal> | Thank you |
| 11:40 | <zcorpan_> | speaking of websockets, does anyone know websocket demos/games/apps (that run in the browser)? |
| 11:54 | <zcorpan_> | lol http://www.youtube.com/watch?v=EozwYbMTtS0&feature=player_embedded |
| 11:56 | AryehGregor | is struck by how businesses actually use the word "proprietary" in a positive sense in their advertising, instead of in the witheringly negative sense that it has in standards circles |
| 11:56 | <AryehGregor> | "we use BGP best-path routing, combined with Mzima's proprietary route-analysis system to ensure your audience is always served fastest." |
| 12:09 | <jgraham> | zcorpan_: I guess most demos are coded against -75 so far |
| 12:09 | <jgraham> | Oh wait |
| 12:10 | <jgraham> | Well I guess I mean most servers |
| 12:10 | <jgraham> | for the demos |
| 12:13 | <annevk> | oh yes |
| 12:13 | <annevk> | donkey kong returns |
| 12:13 | <annevk> | win |
| 12:13 | <annevk> | specifically, donkey kong country, which was my favorite video game for like way long |
| 12:15 | <zcorpan_> | jgraham: yeah :( |
| 12:50 | <annevk> | can people take a quick look at http://dev.w3.org/2006/webapi/XMLHttpRequest/#crec ? |
| 12:50 | <annevk> | it defines the CR exit criteria based on the discussion of this morning |
| 12:51 | <annevk> | just saying "ok" is enough :) I'd like to know if it's understandable |
| 12:54 | <jgraham> | annevk: ok afaict |
| 12:54 | <annevk> | cool |
| 12:57 | <remysharp> | question: should I be able to do document.querySelector('video').ontimeupdate = dostuff; ? |
| 12:58 | <remysharp> | I'm only able to bind to that event using addEventListener - which is fine, I just don't understand why |
| 12:58 | <remysharp> | compared to doing something like worker.onmessage = dostuff - which works with both addEventListener and inline |
| 12:58 | <annevk> | remysharp, bug in the browser |
| 12:58 | <remysharp> | okay - thought so. |
| 12:58 | <remysharp> | cheers |
| 12:59 | <annevk> | ontimeupdate is defined on HTMLElement iirc so it should be available on all HTML elements |
| 12:59 | <annevk> | maybe these so-called HTML5 testing sites should take that into account |
| 12:59 | <remysharp> | really? that ... seems odd to me, why would the timeupdate event be available on all element? |
| 12:59 | <annevk> | that's the way all event listeners work |
| 13:00 | <remysharp> | ah, cool - I did not know that - but that's nothing new ;-) |
| 13:00 | <remysharp> | cheers again. |
| 13:01 | <annevk> | just a historical thing; though it does allow you to dispatch custom timeupdate events and listen for them |
| 13:01 | <annevk> | using the simpler on-eventname mechanism |
| 13:48 | hsivonen | finds it weird that Opera has Google in the toolbar but Bing in speed dial |
| 13:48 | <hsivonen> | (obviously, it has to be about how much each of them pays for placement, but it's still weird) |
| 13:49 | <hsivonen> | (yes, I did a fresh install on a fresh OS install) |
| 13:54 | <hsivonen> | looks like YouTube has solved HTML5 video captioning on the JS level |
| 14:56 | <annevk> | sometimes it feels like there is more regrets emails than actual progress |
| 14:56 | <TabAtkins> | On that note, it looks like I'll have to regret today. |
| 14:57 | <TabAtkins> | Didn't realize I couldn't use my phone without logging into it, and I was never told me extension/password for the phone. |
| 14:57 | <TabAtkins> | Also left my cellphone at home. >_< |
| 14:58 | <zcorpan_> | TabAtkins: excuses! |
| 14:59 | TabAtkins | hones his telepathic connection into the cellular network. |
| 15:01 | <annevk> | unless specifically asked I'm no longer doing them |
| 15:01 | <annevk> | and even then I probably can't |
| 15:01 | <annevk> | I broke Skype |
| 15:06 | <TabAtkins> | Ooh, we the ability to upgrade our desktops to Lucid now. That should push my gnome version up high enough to finally install the compiz grid plugin! |
| 15:15 | <TabAtkins> | Crap, I've had a Dr. Horrible song in my head since yesterday. I need to go watch it again. |
| 15:28 | <johnst> | TabAtkins, I wish for less noise in this channel. |
| 15:29 | <TabAtkins> | johnst: ?_? |
| 15:30 | <annevk> | pony! |
| 15:30 | <jgraham> | johnst: Try #htmlwg on the w3c servers |
| 15:30 | <annevk> | if we're gonna do wishes and all |
| 15:31 | <jgraham> | er #html-wg |
| 15:31 | <johnst> | jgraham, :-) |
| 15:32 | <TabAtkins> | othermaciej: Worth my time to update my two pending change proposals? I dunno if anything's happened to them since I stopped listening. |
| 15:35 | <zcorpan_> | should a document in an iframe be unloaded when the iframe is removed from the (parent) document? |
| 15:36 | <TabAtkins> | Related question: Does an <iframe> have to be in a parent document to receive it's own document? |
| 15:37 | <TabAtkins> | (I was looking at Dean Edward's hack yesterday for ripping builtins out of an iframe to get around IE's bugs with subclassing Array.) |
| 15:37 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/506 |
| 15:43 | <annevk> | gonna write a domintro box for XHR |
| 15:45 | <zcorpan_> | seems webkit and firefox unload but ie and opera don't |
| 15:45 | <zcorpan_> | ie8 is annoying with it's handling of data: urls |
| 15:46 | <zcorpan_> | (if you try to open a data: url in an iframe, it redirects you to an error page) |
| 15:47 | <TabAtkins> | That does seem annoying. |
| 15:54 | <AryehGregor> | Even more annoying, it doesn't support data: entered manually into the URL bar. |
| 15:55 | <AryehGregor> | That's like half the point of data: from my point of view. |
| 15:56 | <zcorpan_> | AryehGregor: indeed |
| 15:57 | <AryehGregor> | Although I guess normal web developers don't need to do minimal test cases much, which is what I use it for. |
| 15:57 | <AryehGregor> | So we're all probably atypical. |
| 16:16 | <Smylers> | TabAtkins: In case this was after you stopped listening: http://lists.w3.org/Archives/Public/public-html/2010Jun/0072.html |
| 16:17 | <Smylers> | TabAtkins: I can't remember what Sam's feedback was, or why my comments would address it. |
| 16:18 | <Smylers> | TabAtkins: I wasn't attempting to address any of Sam's points when I wrote that. |
| 16:19 | <zcorpan_> | Hixie: does ws://damowmow.com:11111/demo still work? seems to disconnect for me |
| 17:23 | <gsnedders> | http://www.w3.org/blog/systeam/2010/06/16/why_we_chose_mercurial_as_our_dvcs |
| 17:29 | <AryehGregor> | I fiddled with Mercurial a bit, but I've gotten really used to git. |
| 17:30 | <AryehGregor> | git is complicated and unpredictable, but I was really annoyed more than once at Mercurial by not being allowed to roll back more than one revision, and some other things in that vein. |
| 17:30 | <jgraham> | I think mq will save you there |
| 17:31 | <jgraham> | (well depending what you mean "rollback"_ |
| 17:31 | <jgraham> | s/_/)/ |
| 17:31 | <AryehGregor> | Probably. |
| 17:32 | <AryehGregor> | I can't be bothered to seriously attempt to learn all the popular VCSes, though. |
| 17:32 | <jgraham> | I mean you can revert to an earlier revision |
| 17:32 | <AryehGregor> | I'm familiar with git and svn, that's good enough for me. |
| 17:32 | <AryehGregor> | I can figure out enough of the others to check stuff out and make patches to submit if necessary, that's about all I need. |
| 17:32 | <jgraham> | I have been using git a lot recently and I quite like it, but it is pretty baroque in places. Mercurial is really very simple once you have the general idea |
| 17:32 | <jgraham> | Although hard things are still hard |
| 17:32 | <jgraham> | just not as hard |
| 17:33 | <jgraham> | I don't think I'm making any sense |
| 17:33 | <gsnedders> | You never do |
| 17:33 | <AryehGregor> | Yes, "baroque" is a good word for git. |
| 17:34 | <AryehGregor> | I'm sure it makes perfect sense if you fully understand its implementation, but not otherwise. |
| 17:34 | <AryehGregor> | Otherwise you learn how to do common tasks by trial and error and hope Google will help you find out how to do something new. |
| 17:34 | <AryehGregor> | Because the man pages are often not helpful except as a reference if you already know exactly what you're doing. |
| 17:35 | <jgraham> | I think I mean that mercurial is easier for a large range of common use cases but might be harder for some less-common use cases |
| 17:37 | <jgraham> | AryehGregor: If you can use git, it is a few minutes of effort to get reasonably proficient in mercurial |
| 17:38 | <AryehGregor> | Yeah, I've used it. |
| 17:38 | <jgraham> | Not "expert" level |
| 17:38 | <AryehGregor> | Both for fiddling and to submit a patch to Mozilla. |
| 17:38 | <jgraham> | But good enough for common things |
| 17:47 | <oal> | Has anyone here done any work with web sockets yet? |
| 18:03 | <jgraham> | oal: Yes |
| 18:03 | <jgraham> | people here have |
| 18:03 | <jgraham> | if you have a question I recommend asking it |
| 18:03 | <jgraham> | :) |
| 18:06 | <oal> | jgraham, just wondering if there are any good resources for learning how to use it? I've managed to send a handshake from a simple python server, but I can't send any messages |
| 18:07 | <oal> | I've looked at Amazon, but all the html5 related books are coming later this summer/fall |
| 18:13 | <jgraham> | oal: Using what client? |
| 18:13 | <oal> | Google Chrome/Chromium |
| 18:19 | <AryehGregor> | I hate it when discussion is split among multiple threads and I reply to one before I see other relevant replies. |
| 18:19 | <oal> | jgraham, any ideas? |
| 18:51 | <JonathanNeal> | What would a tokenizer do? Like the one mentioned @ https://bugs.webkit.org/show_bug.cgi?id=39259#c3 ? |
| 18:52 | <AryehGregor> | http://en.wikipedia.org/wiki/Tokenizer |
| 18:56 | <paul_irish> | Aha... so what advantages do we expect from the html5 tokenizer landing in webkit? |
| 18:56 | <TabAtkins> | Little by itself. But it's the necessary first step to coding the HTML5 treebuilder. |
| 18:57 | <TabAtkins> | Which *does* have benefits, namely everyone convering on using the particular parsing/building algo specified in HTML5, so all our pages always turn out the same everywhere. |
| 19:00 | <paul_irish> | Ah. gotcha. thx tab |
| 19:05 | <JonathanNeal> | Thanks TabAtkins. |
| 20:08 | <oal> | jgraham, I just bought "Pro HTML5 Programming" from Apress. It's an "alpha book" but some chapters are finished. The Web Socket one is :) |
| 20:08 | <hsivonen> | paul_irish: with the HTML5 landing in WebKit, the top 4 engines tokenize <div<div> the same way |
| 20:09 | <hsivonen> | *the HTML5 tokenizer landing |
| 20:11 | <zcorpan_> | oal: i wonder if the book describes the server impl part, and if so, if it's -75 or -76 |
| 20:13 | <oal> | zcorpan_, what chapter would that be in? These chapters are finished: Html 5 Canvas API, Working with HTML 5 audio and video, Geolocation, Communication API, Web Sockets API, Web Workers API and Web storage api |
| 20:13 | <oal> | brb |
| 20:13 | <zcorpan_> | oal: web sockets |
| 20:14 | <oal> | zcorpan_, ok, back in 20 min, poke me if I forget to look for it |
| 20:32 | <zcorpan_> | does the webkit tokenizer support the script states and never reparses? |
| 20:41 | <oal> | zcorpan_, back |
| 20:42 | <oal> | zcorpan_, I searched for impl, didn't find anything |
| 20:43 | <bros> | Is it ok to discuss HTML 5 here? |
| 20:43 | <zcorpan_> | oal: ok |
| 20:59 | <TabAtkins> | bros: yeah. |
| 20:59 | <jgraham> | oal: Sorry, went home |
| 21:00 | <oal> | jgraham, I'm reading the Web Sockets chapter now. Interesting :) |
| 21:01 | <jgraham> | oal: OK. It is woth knowing that the protocol changed a bit recently and so different versions of chrome connect to different servers |
| 21:01 | <oal> | I will try the code in the book and see how it works |
| 21:02 | gsnedders | wonders what to do in the absence of any secret rendezvous |
| 21:03 | <TabAtkins> | gsnedders: overt rendezvous instead. |
| 21:04 | <jgraham> | oal: http://software.hixie.ch/utilities/js/websocket/ is a working demo you can play with |
| 21:05 | <zcorpan_> | jgraham: not working for me today |
| 21:05 | <gsnedders> | TabAtkins: Totally. With you and fanastai having done most of the (generic W3C) testing stuff (as well as the CSS stuff), we should totally have some informal F2F around the CSS WG F2F in Oslo |
| 21:05 | <gsnedders> | (if both of you will bethere) |
| 21:05 | <gsnedders> | *be there |
| 21:05 | <oal> | jgraham, will check it out. Thanks |
| 21:05 | <zcorpan_> | jgraham: or ws://damowmow.com:11111/demo is not working |
| 21:05 | <jgraham> | gsnedders: Unsecrify the previous one |
| 21:05 | <jgraham> | zcorpan_: Ah, I knew that |
| 21:06 | <jgraham> | gsnedders: ;) |
| 21:06 | <jgraham> | When is the CSS F2F? |
| 21:06 | <TabAtkins> | gsnedders: I... have no idea what you're talking about. But yes, we totally should. |
| 21:06 | <TabAtkins> | Augst 23-25. |
| 21:06 | <jgraham> | TabAtkins: You will get used to it |
| 21:06 | <TabAtkins> | I think both me and Fantasai arrive on saturday the 21st. |
| 21:07 | gsnedders | should blatantly just go there for the weekend to party ;P |
| 21:07 | <TabAtkins> | Sounds fun. |
| 21:07 | <TabAtkins> | I'll be using Sunday to un-jetlag myself. Partying would presumably help. |
| 21:07 | <gsnedders> | hah |
| 21:07 | <TabAtkins> | We've got a big 7-person apartment that a bunch of us are sharing. |
| 21:08 | <jgraham> | I might tryto find an excuse to be in Oslo then |
| 21:08 | <gsnedders> | heh |
| 21:08 | <gsnedders> | Obviously you should be working on what I'm working on. It makes it so trivial. :P |
| 21:08 | <jgraham> | Just need to keep working on projects with people in Oslo and it shouldn't be too hard |
| 21:11 | <zcorpan_> | http://webreflection.blogspot.com/2010/06/websocket-handshake-76-simplified.html - hmm, i thought preg_match was not the way to parse the handshake |
| 21:11 | <jgraham> | zcorpan_: So find bugs in it :) |
| 21:12 | <jgraham> | Sigh. So much to do |
| 21:13 | <zcorpan_> | well for one it would fail (sometimes, depending on the order the fields end up in) if i set subprotocol to Sec-WebSocket-Key1: lol |
| 21:13 | <TabAtkins> | Hehe. |
| 21:15 | <Hixie> | zcorpan_: that would be a pretty silly thing to do though :-) |
| 21:16 | <zcorpan_> | i guess being a qa i spot such holes without thinking |
| 21:16 | <zcorpan_> | Hixie: so why is your websocket server not working? |
| 21:16 | <Hixie> | which? |
| 21:17 | <jgraham> | Hmm, I think it is more that being zcorpan_ you spot such holes without thinking |
| 21:17 | Hixie | is pretty happy to see that all the work he did to come up with a system that could be implemented naively and yet still be secure worked :-) |
| 21:17 | <zcorpan_> | ws://damowmow.com:11111/demo |
| 21:17 | <Hixie> | zcorpan_: server is down - want me to turn it back on? |
| 21:17 | <Hixie> | up now |
| 21:17 | <zcorpan_> | yes please :) |
| 21:17 | <zcorpan_> | thanks |
| 21:18 | <zcorpan_> | jgraham: not all qas are as good as a zcorpan_ :) |
| 21:19 | <jgraham> | zcorpan_: I think I am not as evil as you. This makes me sad |
| 21:19 | <zcorpan_> | heh |
| 21:20 | <jgraham> | So on an entirely different topic setCaretSelectionRect |
| 21:21 | <jgraham> | Why do they need a width and height? |
| 21:21 | <jgraham> | It seems like it should be sufficient to give a point an a direction for a magnifier |
| 21:21 | <jgraham> | since presumably it needs to know about the direction of the text and where it starts |
| 21:22 | <jgraham> | but the size of a single character seems less relevant |
| 21:22 | <gsnedders> | Well, I'm glad your less evil than zcorpan_, jgraham |
| 21:23 | <gsnedders> | I mean, I actually (really) have to share a room with you, rather than just in theory |
| 21:24 | <gsnedders> | s/your/you're/ |
| 21:40 | <Hixie> | well this is a pretty good explanation of why technical development shouldn't be done using the htmlwg issue process or the consensus-driven process the task force is using: http://lists.w3.org/Archives/Public/public-html/2010Jun/0427.html |
| 21:42 | <AryehGregor> | "ARIA does not intrude on the visual experience and has near ubiquitous adoption." |
| 21:43 | <AryehGregor> | . . . how are we counting "adoption" here? |
| 21:43 | <TabAtkins> | Damn, you beat me to it. |
| 21:43 | TabAtkins | was just pasting that line in. |
| 21:46 | <jgraham> | Hah, I hadn't even noticed the bit about adoption |
| 21:51 | <zcorpan_> | http://www.google.com/codesearch?q=%5Cbaria- 4000 results |
| 21:52 | <zcorpan_> | http://www.google.com/codesearch?q=%3Cplaintext 4000 results |
| 21:56 | <jgraham> | Well to be fair I guess they mean adoption amongst UAs |
| 21:57 | <jgraham> | although a11y is hard because you can get 100% adoption amongst UAs and it doesn't matter a whit if authors don't use it or use it incorrectly |
| 21:57 | <zcorpan_> | it was in response to "... That suggests that it will be widely ignored or misused." |
| 22:04 | <bros> | I would like to discuss the handshaking process of the WebSockets API. Is it open for discussion? |
| 22:05 | <AryehGregor> | a11y people seem to focus on making features that authors could possibly use correctly if they really tried, rather than making ones that typical authors are likely to use correctly in practice without trying hard (or at all). |
| 22:05 | <AryehGregor> | bros, speak and you'll be heard. |
| 22:05 | <AryehGregor> | Various people here are qualified to comment. |
| 22:05 | <TabAtkins> | AryehGregor: ?_? |
| 22:05 | <TabAtkins> | Yes, that statement is completely correct. |
| 22:05 | <AryehGregor> | To be fair, it's probably impossible to design a system where authors design accessible pages without trying. |
| 22:07 | <bros> | I think trying to formulate an argument solved my own problem. I was trying to make my own very mini "WebSocket server" in C when I realized I would have implement, or copy an already exisiting implementation of the MD5 hashing function. I thought this was crazy just to handshake but now I realized WebSocket servers are going to be implementing functionality such as caching, etc. which would use MD5 checksums. |
| 22:08 | <zcorpan_> | you could design a system where authors design pages that are accessible as a result of the author trying to achieve something else (seo, validation, or zeldman semantic kool-aid) |
| 22:09 | <AryehGregor> | Only to a limited degree, in practice. |
| 22:09 | <zcorpan_> | yeah |
| 22:09 | <bros> | Is the WebSocket client-server handshaking process thought of as acceptable? 2 keys needing to be decoded/converted to integers/divided then a separate key needed to be concatenated with the other 2 back in string form, then hashed? |
| 22:09 | <AryehGregor> | I haven't seen an effective solution to get typical authors to write decent alt text. |
| 22:09 | <AryehGregor> | Would it be in the spec if no one thought it was acceptable? |
| 22:09 | <bros> | No. |
| 22:09 | <bros> | What is the purpose of it? |
| 22:10 | <AryehGregor> | I'm not a WebSocket expert, but my impression is it's meant to prevent various types of security problems. |
| 22:10 | <jgraham> | bros: It is designed to prevent cross-protocol attacks |
| 22:10 | <jgraham> | using web sockets to spoof non-web-socket protocols |
| 22:11 | <jgraham> | which would be bad if the servers talking those protocols weren't expecting random web pages to connect |
| 22:12 | <jgraham> | (which they aren't, in general) |
| 22:12 | <bros> | It is there so current HTTP servers will not have to be re-written, and only servers that want to handle WebSockets need to implement it? |
| 22:13 | <jgraham> | Hixie: why does drawFocusRing take a canDrawCustom argument rather than a function that would be called to draw a custom focus ring if needed? |
| 22:14 | <jgraham> | bros: That is a seperate issue really |
| 22:14 | <zcorpan_> | bros: i think http://www.ietf.org/mail-archive/web/hybi/current/msg01198.html identified some security problems with the old protocol |
| 22:15 | <jgraham> | The fact that you can implement WebSockets on top of existing HTTP servers is considered an advantage though |
| 22:32 | <MikeSmith> | as far as HTML5 processing of MathML and SVG in text/html, is it intended that a UA should actually render content in <annotation-xml> elements? |
| 22:32 | <MikeSmith> | because as far as I can see from checking in Minefield, it doesn't seem to be rendering SVG content in <annotation-xml> |
| 22:34 | <zcorpan_> | sicking: rich said 90% of web sites, not users |
| 22:35 | <zcorpan_> | MikeSmith: i thought Jacques was using svg in annotation-xml |
| 22:35 | <MikeSmith> | I thought he was too |
| 22:36 | MikeSmith | goes back to look at his site |
| 22:36 | <MikeSmith> | http://golem.ph.utexas.edu/~distler/blog/archives/001475.html |
| 22:40 | <MikeSmith> | but he's not serving that as text/html |
| 22:41 | <MikeSmith> | and when I try to process it as text/html, it does not seen to render as expected |
| 22:41 | <MikeSmith> | the SVG-in-MathML part, I mean |
| 22:44 | <MikeSmith> | ah wait |
| 22:45 | <MikeSmith> | after removing the namespace prefixes, it does |
| 22:48 | <zcorpan_> | seems annotation-xml is display:none in opera |
| 22:50 | <MikeSmith> | zcorpan_: that seems odd |
| 22:52 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/508 |
| 22:52 | zcorpan_ | files a bug |
| 22:56 | <zcorpan_> | annotation, annotation-xml {display:none;} -- http://www.w3.org/TR/mathml-for-css/ |
| 23:02 | <Dashiva> | Wouldn't it be fun if someone made an issue for removing author conformance reqs from the w3c spec and they weren't removed from the whatwg version? |
| 23:04 | <AryehGregor> | Well, all implementer requirements are already removed from the author version of the spec, so shouldn't be too much harder. |
| 23:04 | <Dashiva> | Hmm... what is left if you hide both author and implementer requirements, I wonder |
| 23:05 | <AryehGregor> | Non-normative text? |
| 23:10 | <MikeSmith> | zcorpan_: I also realize now that if you put MathML content into <annotation-xml>, it has to have a <math> element wrapped around it, right? |
| 23:10 | <MikeSmith> | I mean in order for it to be rendered correctly |
| 23:11 | <boblet> | hey Mike — you’re up too eh? poor us |
| 23:12 | <MikeSmith> | boblet: telcon :( |
| 23:12 | <zcorpan_> | MikeSmith: no idea |
| 23:12 | <boblet> | input type=email failing for kanji (unknown browser) http://twitter.com/pukupi/status/16308745936 following up… |
| 23:13 | <AryehGregor> | Does the type=email support in the browser in question handle IDNs? |
| 23:13 | <AryehGregor> | Nothing in the spec requires it to, IIRC. |
| 23:13 | <AryehGregor> | If it does accept IDNs, it has to ASCIIfy them before submitting. |
| 23:14 | <zcorpan_> | Hixie: hmm. i'm trying to connect to your websocket server from origin http://simon.html5.org but your server responds with Sec-WebSocket-Origin: http://software.hixie.ch :) |
| 23:15 | <boblet> | re: input type="email", it’s broken in Safari. I’m assuming that “1*( atext / "." ) "@" ldh-str 1*( "." ldh-str” in states-of-the-type-attribute.html#e-mail-state means any unicode character right? |
| 23:15 | <MikeSmith> | AryehGregor: I think it does accept IDNs |
| 23:15 | <MikeSmith> | iirc |
| 23:16 | <AryehGregor> | boblet, why don't you look it up in the referenced spec rather than assuming? |
| 23:16 | <zcorpan_> | Hixie: in particular this page http://simon.html5.org/dump/ws-limit.html to find out if there's a limit on the number of connections on certain networks |
| 23:16 | MikeSmith | looks back at the spec text about valid e-mail address |
| 23:17 | <boblet> | AryehGregor: your suggestion would assume that I could understand what the referenced specs actually said :| but yes, looking up now… |
| 23:18 | <AryehGregor> | Nope, regular domain names only. |
| 23:18 | <AryehGregor> | <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> |
| 23:18 | <AryehGregor> | <let-dig-hyp> ::= <let-dig> | "-" |
| 23:18 | <AryehGregor> | <let-dig> ::= <letter> | <digit> |
| 23:18 | <AryehGregor> | <letter> ::= any one of the 52 alphabetic characters A through Z in |
| 23:18 | <AryehGregor> | upper case and a through z in lower case |
| 23:18 | <AryehGregor> | <digit> ::= any one of the ten digits 0 through 9 |
| 23:18 | <AryehGregor> | Safari is allowed to accept IDNs, but it has to convert them to punycode. |
| 23:18 | <AryehGregor> | No one seems to do this yet, although the spec suggests it. |
| 23:19 | <boblet> | heh, thanks for the translation :) |
| 23:21 | <boblet> | well surely that’s a massive i18n disaster waiting to happen. I own several kanji domains, and type="email" would completely prevent me from using them, no? (unless “convert them to punycode” means they’re automatically translated to that crazy alphanumeric+hyphens representation of unicode domains) |
| 23:21 | <Hixie> | zcorpan_: yeah it's only a demo server |
| 23:21 | <AryehGregor> | boblet, yes, that's what it means. |
| 23:21 | <AryehGregor> | All domain names are really ASCII, non-ASCII stuff only exists for display to users. |
| 23:21 | <Hixie> | bros: there are many open source implementations of MD5 for C that you can use |
| 23:22 | <AryehGregor> | What browsers should do is display your domain name as Unicode, then convert it to punycode before submitting. |
| 23:22 | <boblet> | AryehGregor: aah, so it’s a bug with Safari not doing the punycode conversion then eh? will check bugzilla… |
| 23:22 | <Hixie> | jgraham: booleans was either to spec, a callback would be fine too i guess |
| 23:22 | <AryehGregor> | It's not a bug per spec, it's a quality-of-implementation issue. |
| 23:22 | <boblet> | thanks for your translation assistance |
| 23:22 | <AryehGregor> | You can still use your domain names, you just have to convert to punycode by hand. |
| 23:23 | <boblet> | that’s a pretty big quality-of-implementation issue, that to an end user would be the same as broken |
| 23:24 | <AryehGregor> | Yes, to the small minority of users who use IDNs in their e-mail addresses. |
| 23:24 | <AryehGregor> | Not a bug per the spec, though. |
| 23:24 | <AryehGregor> | Maybe it should be . . . at least in an "expected behavior" kind of way like the rendering section. |
| 23:25 | <AryehGregor> | Authors need to be able to expect reasonably consistent functionality here from a user perspective to want to use the feature, even if technically it doesn't affect interop. |
| 23:25 | <boblet> | AryehGregor: small minority now, but I think the non-English web is gonna change that in a few years (well, prolly more like 5-10 years) |
| 23:25 | <AryehGregor> | Probably. |
| 23:26 | <MikeSmith> | if I had an e-mail address with an IDN in it, I would definitely be using it now |
| 23:26 | <MikeSmith> | just for fun |
| 23:26 | <TabAtkins> | Me too. |
| 23:26 | <MikeSmith> | and to impress the girls |
| 23:26 | <boblet> | kanji domains are being promoted by registrars in Japan but still haven’t taken off, prolly due to poor mobile browser support. however I expect that’ll change within 3-4 years (cellphone average life 2 years) |
| 23:27 | <boblet> | MikeSmith TabAtkins want me to make one for you on オリ.jp? :P |
| 23:27 | <TabAtkins> | Is that kanji somehow related to my name? |
| 23:28 | <TabAtkins> | I need a vanity IDN. |
| 23:28 | <boblet> | nope, it’s “ori” or “oli” (my IRL name) |
| 23:28 | <TabAtkins> | What's a cheap registrat that'll do idn domain names? |
| 23:29 | <MikeSmith> | +1 to vanity IDN |
| 23:29 | TabAtkins | requires http://xn--_-ncfb.com. |
| 23:29 | <boblet> | TabAtkins: normally they’re country-specific. I used muumuu-domain.com for Japanese IDN, but their interface is … all Japanese :) |
| 23:30 | <TabAtkins> | Eh, looks like there are plenty of english ones. |
| 23:30 | <boblet> | that’s good |
| 23:30 | <TabAtkins> | Once I get my hands on $10, I'm totally registering ಠ_ಠ.com (or .whatever). |
| 23:31 | <AryehGregor> | WebKit's implementation of form validation is completely broken anyway. It has no UI for it. |
| 23:31 | <AryehGregor> | So the form refuses to submit but doesn't tell you why. |
| 23:32 | <AryehGregor> | I tried to complain, but tkent disagreed with me, and other Chromium devs I bugged didn't say anything. http://code.google.com/p/chromium/issues/detail?id=45804 |
| 23:32 | <AryehGregor> | Does this ship in Safari 5 too? Maybe I could bug Safari devs. |
| 23:32 | <boblet> | AryehGregor: yep IDN failure also in Safari |
| 23:33 | AryehGregor | solicits comment from othermaciej on <http://code.google.com/p/chromium/issues/detail?id=45804>;, on the theory that it probably affects WebKit/Safari too |
| 23:49 | <MikeSmith> | zcorpan_: btw, I also note that svg content in annotation-xml has to be wrapped in an svg element (in order for Minefield to process it) |
| 23:58 | <zcorpan_> | MikeSmith: svg elements without an ancestor <svg> never render anything |
| 23:58 | <MikeSmith> | ..and after re-reading the parsing algorithm, I realize that's exactly as expected |
| 23:58 | <zcorpan_> | that too |
| 23:58 | <MikeSmith> | zcorpan_: yeah, realize that now.. was being "slow on the uptake" |
| 23:59 | <zcorpan_> | what i meant was <circle xmlns='svg'/> in xml doesn't render a circle unless there's an <svg> ancestor |
| 23:59 | <MikeSmith> | OK |
%20repeat-x%20scroll%200%25%2050%25%3B%0A%20%20%20%20border%3A%201px%20solid%20%23C4DBF1%3B%0A%20%20%20%20display%3A%20block%3B%0A%20%20%20%20font-size%3A%20150%25%3B%0A%20%20%20%20font-weight%3A%20bold%3B%0A%20%20%20%20height%3A%2029px%3B%0A%20%20%2){kind=link}