| 00:00 | <karlcow> | http://www.w3.org/TR/1998/WD-html-in-xml-19981205/ |
| 00:07 | <AryehGregor> | Okay, answer submitted. http://www.w3.org/2002/09/wbs/40318/html5-license-poll-v3/results |
| 00:09 | <Hixie> | man, you have got to love the vote of confidence that is "[a non-free license] is necessary to maintain W3C as a trusted and reputable source of definitive technical specifications" |
| 00:52 | <Yuhong> | "then when that concluded with the creation of a doomed wg on compound documents and nothing for html, we announced the whatwg list and moved xforms basic to the whatwg site " |
| 00:53 | <Yuhong> | Personally what I would have asked is an XHTML2 spec that is tag level compatible with XHTML1 (and HTML4 via Appendix C) |
| 00:55 | <Yuhong> | Of course, it is too late anyway. |
| 01:54 | <erlehmann> | edbrowse is the standard edi^W browser |
| 02:09 | <erlehmann> | oh, i tried it |
| 02:09 | <erlehmann> | edbrowse *is* indeed interesting |
| 03:28 | <MikeSmith> | Hixie: I'm writing <select required> checking for the validator and I the spec seems quite clear but I want to doublecheck |
| 03:28 | <MikeSmith> | so, question: |
| 03:28 | <MikeSmith> | the following should be valid, right? |
| 03:28 | <MikeSmith> | <select required> |
| 03:28 | <MikeSmith> | <option></option> |
| 03:28 | <MikeSmith> | </select> |
| 03:29 | <MikeSmith> | and the following should not be? |
| 03:29 | <MikeSmith> | <select required> |
| 03:29 | <MikeSmith> | <option value=1>foo</option> |
| 03:29 | <MikeSmith> | </select> |
| 03:29 | <Hixie> | i assume we're ignoring the <option> here, right? attribute-wise? |
| 03:29 | <Hixie> | or should i check the option requirements too |
| 03:30 | <MikeSmith> | there are not requirements on the option in that case, as far as I can see |
| 03:30 | <MikeSmith> | so, no, anyway, you don't need to check the option requirements for that first case |
| 03:30 | <MikeSmith> | I just meant is is valid as far as the select goes |
| 03:30 | <Hixie> | in the first case, the option has to have a value="" if its contents aren't "". |
| 03:31 | <Hixie> | the second one is invalid, indeed |
| 03:31 | <Hixie> | so yes, valid and not valid |
| 03:32 | <Hixie> | the first might want to emit a warning that the author probably forgot to give the text of the placeholder label option |
| 03:32 | <Hixie> | dunno how much linting you're doing |
| 03:32 | <MikeSmith> | OK |
| 03:32 | <MikeSmith> | hmm |
| 03:33 | <MikeSmith> | but now I do think I'm misunderstanding something |
| 03:33 | <MikeSmith> | which ish, how do you give the text of the placeholder label option |
| 03:33 | MikeSmith | looks back at the spec |
| 03:33 | <Hixie> | in the label="" or textContent of the <option> |
| 03:34 | <MikeSmith> | ok |
| 03:35 | <MikeSmith> | but the spec says, "if the value of the first option element in the select element's list of options (if any) is the empty string, and that option element's parent node is the select element (and not an optgroup element), then that option is the select element's placeholder label option." |
| 03:35 | <MikeSmith> | should that be "is *not* the empty string"? |
| 03:36 | <Hixie> | sorry afk brb |
| 03:36 | <MikeSmith> | ok |
| 03:43 | <MikeSmith> | Hixie: (when you get back), so it seems like maybe it should say that the value attribute is empty (or not specified), but the option must have textContent |
| 03:47 | <MikeSmith> | because, unless I'm missing something, I don't see how the option element can serve as an actual placeholder label option if the "value of the option element" (= "the value of the value attribute, if there is one, or the textContent of the element, if there isn't") has to be the empty string |
| 03:51 | <MikeSmith> | in other words, the current spec text seems to require the following to be reported as invalid |
| 03:51 | <MikeSmith> | <select required> |
| 03:51 | <MikeSmith> | <option>Choose one of the following</option> |
| 03:51 | <MikeSmith> | <option value=1>foo</option> |
| 03:51 | <MikeSmith> | <option value=2>bar</option> |
| 03:51 | <MikeSmith> | </select> |
| 03:53 | <MikeSmith> | because it must have a placeholder label option, but the value of the first option element is not the empty string, so it does not have a placeholder label option |
| 04:04 | <Hixie> | MikeSmith: back |
| 04:04 | <MikeSmith> | hey |
| 04:05 | <Hixie> | MikeSmith: right, if you have required in that case you also have to have <option value="">label</option> |
| 04:05 | <Hixie> | required="", i mean |
| 04:05 | <MikeSmith> | ok |
| 04:05 | <Hixie> | because otherwise there's no point having required="" -- it'd be required anyway |
| 04:05 | <Hixie> | you can't _not_ give a value in that case |
| 04:05 | <Hixie> | so marking it required="" is worthless |
| 04:05 | <MikeSmith> | right, but that's not what the spec seems to say |
| 04:06 | <Hixie> | oh? |
| 04:06 | Hixie | looks |
| 04:06 | <Hixie> | in that case, it doesn't have a placeholder label option, and it must have a placeholder label option, right? |
| 04:07 | <Hixie> | it doesn't have one because the value of the first option is "1", so the first option is not a placeholder label option |
| 04:07 | <MikeSmith> | oh |
| 04:08 | <MikeSmith> | but the first option has no value attribute… |
| 04:08 | <MikeSmith> | the value of the second option is 1 |
| 04:08 | <Hixie> | oh |
| 04:08 | <Hixie> | sorry |
| 04:08 | <Hixie> | i mean the value of the first option is "Choose one of the following" |
| 04:08 | <MikeSmith> | yeah |
| 04:09 | <MikeSmith> | OK |
| 04:09 | <MikeSmith> | I think I see what the purpose of this is now |
| 04:09 | <Hixie> | you probably want the validator to notice when the first one have a value="non-empty" and give a distinct error than the case where it is simply missing a value="" (but has textContent, as opposed to <option label="choose one of the following">, which would be fine) |
| 04:09 | <Hixie> | because the error message would be confusing otherwise |
| 04:10 | <MikeSmith> | OK |
| 04:11 | <MikeSmith> | so sorry if I'm being daft here, but if the following is not OK, what should it be changed to? |
| 04:11 | <MikeSmith> | <select required> |
| 04:11 | <MikeSmith> | <option></option> |
| 04:11 | <MikeSmith> | <option value=1>foo</option> |
| 04:11 | <MikeSmith> | <option value=2>bar</option> |
| 04:11 | <MikeSmith> | </select> |
| 04:14 | <Hixie> | it's fine, from a validation point of view |
| 04:14 | <MikeSmith> | OK, but what I'm getting at is, the spec currently says that for an option to be a placeholder label option, its "value" must be the empty string |
| 04:15 | <MikeSmith> | where "value" is defined as "the value of the value attribute, if there is one, or the textContent of the element, if there isn't" |
| 04:15 | <Hixie> | right |
| 04:15 | <Hixie> | (hm, we should probably strip spaces before and after the textContent, for sanity, so that omitting the </option> in the case above doesn't matter, but that's another story) |
| 04:16 | <Hixie> | (i'll file a bug) |
| 04:16 | <MikeSmith> | so that would seem to mean that <option value="">label</option> cannot be a placeholder label option |
| 04:16 | <Hixie> | sure it can |
| 04:16 | <Hixie> | value="" is good |
| 04:16 | <MikeSmith> | OK but the "value" of the option is non-empty |
| 04:16 | <MikeSmith> | because it has textContent |
| 04:16 | <Hixie> | the value is the value of the value attribute, if there is one |
| 04:17 | <MikeSmith> | ah |
| 04:17 | <MikeSmith> | yeah |
| 04:17 | <MikeSmith> | thanks for your patience :) |
| 04:17 | <Hixie> | no worries |
| 04:18 | <Hixie> | this stuff is inane, and i make enough mistakes that half the time your questions are just pointing out mistakes i made :-) |
| 04:18 | <MikeSmith> | heh |
| 04:18 | <MikeSmith> | not sure that's true, but thanks for saying it :) |
| 04:24 | <karlcow> | I wish there was a way to do |
| 04:24 | <karlcow> | X-viewport: content="width=device-width" in HTTP headers |
| 04:25 | <MikeSmith> | Hixie: so why not have the spec say that for <select required>, its first option child must have a value="" attribute specified? |
| 04:27 | <Hixie> | MikeSmith: we could do that, but in the case of <option label=".."/> it's a bit ugly to require an otherwise redundant value="" as well |
| 04:27 | <MikeSmith> | OK |
| 04:28 | <MikeSmith> | I will implement it as currently specced so that we have something concrete to test with in the validator |
| 04:28 | <Hixie> | cool |
| 04:29 | <Hixie> | i just filed a bug about the definition of /option label/ that you might want to look at |
| 04:29 | <MikeSmith> | but I should point out to you that as far as I can see, the spec currently doesn't say anything about the label attribute providing the text for the placeholder label option |
| 04:29 | <MikeSmith> | OK, I'll look at that bug |
| 04:32 | Hixie | looks |
| 04:35 | <Hixie> | it doesn't say anything special about the placeholder label option vs other options as far as rendering goes |
| 06:21 | <zcorpan> | heh, EventSource.OPEN and EventSource.CLOSED are both 0 in chrome |
| 06:21 | <zcorpan> | yay for constants |
| 06:40 | <erlehmann> | edbrowse -d0 >&2 |festival --tts |
| 06:40 | <erlehmann> | funny :) |
| 06:58 | <hsivonen> | Hixie: I'm back here now |
| 07:17 | <MikeSmith> | Hixie, hsivonen: fyi, I pushed my workspace implementation of <select required> checking to http://www.w3.org/html/check for testing |
| 07:17 | <MikeSmith> | hsivonen: will send you the patch now |
| 07:19 | <Hixie> | hsivonen: if i ping you without actually asking something it's usually because i'm working on some bug that i think you have an opinion on, and if you're not around i'll just post my question to the bug :-) |
| 07:21 | <Hixie> | hsivonen: in this particular case, i think it was http://www.w3.org/Bugs/Public/show_bug.cgi?id=12100 |
| 07:26 | <hsivonen> | Hixie: commented on the bug |
| 07:26 | <Hixie> | awesome, thanks |
| 07:40 | <hsivonen> | MikeSmith: I replied |
| 07:41 | <MikeSmith> | thanks |
| 08:36 | <hsivonen> | I think http://html5.org/tools/web-apps-tracker?from=6078&to=6079 didn't actually "clarify" things. |
| 08:39 | <Hixie> | that's because you still think they mean "italics" and "bold" |
| 08:39 | <hsivonen> | Hixie: we've always been at war with Eastasia |
| 08:42 | <Hixie> | i do not claim that they did not once mean "italics" and "bold" |
| 08:42 | <Hixie> | so i think that's an inappropriate attempt at dismissing my position using a platitude |
| 08:47 | <hsivonen> | Hixie: granted, I should have come up another redefinition-related quote that doesn't imply retroactive redefinition. |
| 08:48 | <Hixie> | or you could use your own words :-) |
| 08:49 | <hsivonen> | :-) |
| 08:49 | <Hixie> | i'm updating the terms used in the stability boxes in the spec... any idea of a better term for "first draft", to mean the first attempt at specifying something? |
| 08:49 | <Hixie> | "first attempt" was my other idea |
| 08:49 | <Hixie> | but both kinda suck |
| 08:49 | <othermaciej> | in Newspeak, <b> is defined to serve the needs of the people |
| 08:50 | <zcorpan> | Hixie: "Don't use this yet LOL" |
| 08:51 | <zcorpan> | Hixie: or follow the W3C naming and call it "Last attempt" |
| 08:51 | <othermaciej> | "unstable"? |
| 08:51 | <othermaciej> | "experimental"? |
| 08:51 | <othermaciej> | (not sure if that matches the intent) |
| 08:52 | <Hixie> | i'll try "Experimental draft" for now maybe |
| 08:53 | <Hixie> | search for "== STATUS" in http://www.whatwg.org/specs/web-apps/current-work/status.js for the new list |
| 09:15 | <jgraham> | Aren't the real statuses "Unimplemeneted", "experimentally implemented", "Multiple interoperable implementations" |
| 09:17 | <Hixie> | "experimentally implemented" doesn't correspond to a state in the spec |
| 09:17 | <Hixie> | and there are definitely more states than just "no" and "yes" |
| 09:17 | <Hixie> | :-) |
| 09:17 | <jgraham> | Yes it does |
| 09:17 | <jgraham> | It corresponds to what W3C woudl call "Last Call" |
| 09:18 | <jgraham> | i.e. if you don't like this comment soon before more people implement it |
| 09:18 | <Hixie> | oh i thought you meant a feature implemented as an experiment before the spec is written |
| 09:18 | <Hixie> | sorry |
| 09:18 | <jgraham> | Ah |
| 09:18 | <Hixie> | yeah, those are a subset of the states |
| 09:18 | <Hixie> | see the script for the full list |
| 09:23 | <jgraham> | Hixie: The states there don't seem to be much like the ones I said at all |
| 09:25 | <Hixie> | jgraham: unimplemented = TBW, OCBE, FD, WD; implemented = LC, CR; multiple = REC |
| 09:25 | <jgraham> | Also I agree with hsivonen about the interesting use of the word "clarify" to mean "make more unlike reality" in the <b> and <i> definitions |
| 09:25 | <Hixie> | authoring conformance requirements aren't about past reality they're about future reality |
| 09:25 | <Hixie> | they're about best practices, and what we can most highly recommend to authors |
| 09:26 | <Hixie> | they're very much unlike implementation conformance criteria, in that respect |
| 09:26 | <hsivonen> | Hixie: not entirely true in a world where people have legacy sites to work with |
| 09:26 | <Hixie> | (which is why the decision to make <table> not entirely non-presentational in the w3c copy is just a bad decision) |
| 09:26 | <jgraham> | Hixie: My point about the statuses, such as it was, was that statuses could be explicitly about implementations rather than having abstract states and having to tell people who they map onto reality |
| 09:26 | <Hixie> | hsivonen: how not? |
| 09:27 | <Hixie> | jgraham: we already have explicit implementation status information, so that would be redundant |
| 09:27 | <Hixie> | the states are not abstract, they're descriptions of the quality of the text |
| 09:27 | <hsivonen> | Hixie: if a validator whines too much about legacy content on points that take effort to fix but that have dubious payoff, the validator isn't really helping the author and the author might opt not to validate |
| 09:28 | <jgraham> | Hixie: From the reader's point of view they're abstract |
| 09:28 | <hsivonen> | Hixie: which would be bad, because the author would then also miss out on useful error messages |
| 09:28 | <Hixie> | hsivonen: i'll be immediately convinced of that argument's relevance to this particular problem as soon as you are able to determine whether <b> is being used for bold or for keywords. |
| 09:28 | <Hixie> | programatically |
| 09:28 | <jgraham> | About <b> and <i>: the glorious future where people never use them to mean bold or italic will likely never happen. Even if it did it wouldn't be a big win for anyone |
| 09:29 | <Hixie> | hsivonen: when it comes to cases that _can_ be programmatically detected, i think we've done a good job of walking that line, though |
| 09:29 | <hsivonen> | Hixie: how's that a prerequisite for my point? |
| 09:29 | <Hixie> | hsivonen: either i misunderstood your point, or your point doesn't apply to a case where you wouldn't ever show an error message regardless of the definition we're talking about |
| 09:30 | <jgraham> | The main bad effect is that people won't take the rest of the spec seriously |
| 09:30 | <jgraham> | Not that they won't take validators seriously |
| 09:30 | <Hixie> | jgraham: re the states being abstract, i don't really see how "this is brand new first-draft experimental text" vs "i think we are ready for implementations" is "abstract", but if it is, then i guess i think we need abstraction here. |
| 09:31 | <Hixie> | if people are going to dismiss the entire spec just because <i> is defined in a media-independent way, then i think we have bigger problems. |
| 09:31 | <Hixie> | like, why on earth isn't the rest of the spec useful enough that it overcomes this minor issue. |
| 09:32 | <jgraham> | Hixie: The "How do I suggest a feature" FAQ suggests implementations may preceed spec text so the smooth transition implied by the current states doesn't man much |
| 09:32 | <jgraham> | Not the whole rest of the spec |
| 09:32 | <jgraham> | But the other semantic requirments |
| 09:32 | <jgraham> | Including the ones that actually matter a bit |
| 09:32 | <jgraham> | Like not using <table> for layout |
| 09:33 | <Hixie> | i don't see how anything smooth is implied. certainly no smoothness was intended to be implied. |
| 09:33 | <Hixie> | i think the w3c has done far more damage to the tables-for-layout issue than we could possibly do even if we defined <i> to mean "ice cream" |
| 09:33 | <jgraham> | That is true |
| 09:33 | <jgraham> | But it's only one example |
| 09:34 | <jgraham> | and doesn't excuse us anyway |
| 09:34 | <Hixie> | but i also think the people who are most likely to care about <table> being media-independent are the same people who are likely to appreciate <i> being media-independent |
| 09:34 | <Hixie> | so i don't really buy the premise of your argument |
| 09:35 | <jgraham> | Well I care about <table> but don't really care if people use <i> to mean "I want this text to be italic" |
| 09:35 | <jgraham> | Because non-visual UAs have to deal with that anyway |
| 09:35 | <jgraham> | and it seems to be way down the list of problems they have |
| 09:35 | <zcorpan> | jgraham: do you care if people use <em> to mean "I want this text to be italic"? |
| 09:36 | <jgraham> | zcorpan: I think that is a bigger problem |
| 09:36 | <jgraham> | (and one that is encouraged by demonising <i>) |
| 09:37 | <Hixie> | we don't demonise <i>, we give it what imho is a rather succint definition that maps surprisingly well to real good-practice usage (i.e. not pure styling where an entire section is italics, but more phrasing-like usage), in such a way that authors can continue to use it with no fear of media-dependence |
| 09:38 | <Hixie> | personally i am quite happy with where we are with <i>, <b>, <small>, and even <u> which i have come to terms with |
| 09:38 | <Hixie> | i don't really see what value we would have in introducing <font>-like definitions for any of them |
| 09:39 | <hsivonen> | Hixie: are there Web authors other than you and fantasai who use <i> correctly as specced as a result of reading and understanding the spec? (as opposed to by accident) |
| 09:39 | <Hixie> | no idea |
| 09:39 | <jgraham> | I don't see that any UA can treat <i> as currently defined different to <span style="font-style:italic"> |
| 09:40 | <Hixie> | dunno how one would measure that |
| 09:40 | <jgraham> | So whatever media independence we have would be equally true if we defined that as a synonym |
| 09:41 | <Hixie> | same can be said of <em> and <cite> |
| 09:41 | <Hixie> | so i dunno that that is relevant |
| 09:41 | <Hixie> | anyway, i really should go to bed |
| 09:41 | <jgraham> | Not really. I would expect an AT to read <em> in a difference voice, for example |
| 09:41 | <jgraham> | I might be wrong in that expectation ofc |
| 09:41 | <hsivonen> | jgraham: <em> different voice from <i>? |
| 09:42 | <jgraham> | hsivonen: That depends how many people are using <i> to mean <em> I guess |
| 09:42 | <hsivonen> | I'd expect the best AT user experience to come from rendering <em> and <i> the same way by default regardless of medium, because they are rendered the same way on the medium that authors test the most |
| 09:43 | <hsivonen> | jgraham: of course, it should be possible to test and find out what implementations actually do! |
| 09:43 | <hsivonen> | as opposed to theorizing about it |
| 09:44 | <jgraham> | Indeed |
| 10:41 | <hsivonen> | I love how the HTML 4.01 spec italicizes "Standard Generalized Markup Language" not as <cite>, not as <i> but as <dfn> |
| 10:56 | <hsivonen> | Unicode srsly! Where's my RIGHTWARDS ARROW WITH CORNER UPWARDS? |
| 10:59 | <reggna> | Hehe, all i find is RIGHTWARDS ARROW WITH TIP UPDARDS. :P |
| 11:00 | <hsivonen> | jgraham: from Steve on Twitter: http://www.paciellogroup.com/blog/2008/02/screen-readers-lack-emphasis/ |
| 11:00 | <hsivonen> | reggna: thanks! |
| 11:01 | <jgraham> | hsivonen: Interesting. It would be interesting to hear what changed in 3 years |
| 13:28 | <othermaciej> | VoiceOver doesn't report any bold or italic by default, and while it can be set to do so, Safari doesn't seem to respect that (I'll have to find out if this is a bug) |
| 13:31 | <jgraham> | "Any bold or italic" including <em> and <strong>? |
| 13:46 | <othermaciej> | well, since it doesn't work in Web content I can't test that |
| 13:46 | <othermaciej> | oh, I see what you are asking |
| 13:48 | <othermaciej> | it does not apply voice changes for em/strong |
| 13:49 | <othermaciej> | for bold and italic in apps that support it, it just announces "bold" or "italic", it doesn't use a different voice |
| 19:43 | <Hixie> | "Adobe does not wish the specification to fork, since we believe that this would fragment the Web." |
| 19:43 | <Hixie> | you really have to love the irony |
| 19:48 | <othermaciej> | I wonder if they have software that supports any of the existing HTML forks |
| 19:48 | <Hixie> | i also like the implication that anyone actually wishes the specifications to fork |
| 19:50 | <Hixie> | reminds me of the far more serious issue of abortion rights, where anti-reproductive-rights advocates argue that abortions should be illegal because "we don't want abortions", as if the pro-reproductive-rights advocates actually want to have abortions recreationally or something |
| 19:51 | <AryehGregor> | Well, in that case the anti-abortion people actually do tend to oppose abortions much more strongly than the pro-abortion rights people, in extreme cases considering abortion murder. That's the official Catholic position, right? |
| 19:51 | <AryehGregor> | I don't think it's tenable to support any abortion rights at all if you think abortion is wrong *enough*, e.g., on the level of murder. |
| 19:52 | <Philip`> | What if you support murder? |
| 19:52 | <othermaciej> | I wonder if this will end up the most-responded-to HTML WG survey ever |
| 19:52 | <othermaciej> | I can't remember the previous record |
| 19:52 | <AryehGregor> | We can always rely on Philip` to throw monkey wrenches from left field into seemingly sound logic. |
| 19:52 | <reggna> | Pro murder but anti-abortion? |
| 19:52 | <AryehGregor> | othermaciej, well, the large majority of surveys explicitly say not to answer if you're just repeating others' objections, while in this one many people voted without saying anything. |
| 19:53 | <Hixie> | AryehGregor: yeah it's not a good analogy, it just reminded me of it |
| 19:53 | <AryehGregor> | reggna, maybe you only think murder is okay if the victim has the opportunity to fight back. |
| 19:53 | <reggna> | AryehGregor: Ah, that's true. |
| 19:53 | <reggna> | Got to love the fight! |
| 19:53 | <othermaciej> | there are older surveys that were not objection polls in the style of the issue surveys |
| 19:53 | <Philip`> | What about the "should we adopt the WHATWG's HTML5 spec or doom ourselves to irrelevance before even starting" survey from years ago? |
| 19:53 | <othermaciej> | this may be the record for most answered: http://www.w3.org/2002/09/wbs/40318/htmlbg/results |
| 19:53 | <AryehGregor> | Maybe I wasn't around for those. |
| 19:53 | <Philip`> | Yeah, that one |
| 19:56 | <othermaciej> | there were a bunch of others in that era that drew ~80-100 responses |
| 19:57 | <othermaciej> | for entertainment, check out these results too: http://www.w3.org/2002/09/wbs/40318/req-gapi-canvas/results |
| 19:58 | <Hixie> | AryehGregor: yt? |
| 19:58 | <AryehGregor> | Hixie, yes. |
| 19:58 | <Hixie> | AryehGregor: for http://www.w3.org/Bugs/Public/show_bug.cgi?id=12213 you suggest adding a note for fakepath |
| 19:58 | <AryehGregor> | Yes. |
| 19:58 | <Hixie> | AryehGregor: it turns out fakepath is mentioned in two places. one is where the bug reporter reported the bug from, which is in class=impl text |
| 19:58 | <Hixie> | AryehGregor: the other is in a place more relevant to authors, namely in the input type=file section |
| 19:59 | <Hixie> | AryehGregor: that section mentions fakepath as part of a big note on how to use it |
| 19:59 | <Hixie> | AryehGregor: does this affect your position? |
| 20:01 | <AryehGregor> | Hixie, not really. I certainly wouldn't assume either that authors don't read implementer stuff, or that implementers won't want to have a one-line explanation of WTF things like this so that they know they're not hallucinating. |
| 20:01 | <Hixie> | should i just point to the other one, or have another similar explanation? |
| 20:01 | <AryehGregor> | It's like one line either way, so I don't think it makes a difference. |
| 20:02 | <Hixie> | the other one is far more than one line |
| 20:02 | <Hixie> | there's sample code and everything |
| 20:02 | <AryehGregor> | Well, so you can point to that, sure. |
| 20:02 | <Hixie> | k |
| 20:04 | <Philip`> | Maybe you need a sic element to mark sections where the reader might think they're hallucinating, to indicate that it really is that crazy |
| 20:39 | <zcorpan> | Philip`: we could add a warning, "If you have smoked something funny you may be hallucinating." |
| 20:42 | <Philip`> | "If you haven't, maybe you should before reading further" |
| 20:44 | <zcorpan> | but then we'd need another conformance class: the reader |
| 20:45 | <zcorpan> | and two interoperable readers that smoke something funny (unless they have understood the risks of not smoking and have a valid reason for not smoking) |
| 20:48 | <jgraham> | Hmm, no response from anyone at Apple yet |
| 20:57 | <zcorpan> | jgraham: you need to follow that up with a conspiracy theory |
| 21:01 | <jgraham> | Oh sorry |
| 21:01 | <jgraham> | Erm |
| 21:02 | <jgraham> | If you play Let It Be backwards it reveals that Paul McCartney had a secret plot to kill Steve Jobs in 2011 so they are all in mourning? |
| 21:02 | <jgraham> | And therefore unable to express an opinion |
| 21:02 | <zcorpan> | holy shit! |
| 21:05 | <zcorpan> | maybe he failed to kill him the first time and that's why he got ill |
| 21:05 | <jwalden> | steve jobs eats cheez whiz |
| 21:06 | <Philip`> | I've heard they're planning to replace Steve Jobs with bin Laden who they secretly employed with the cover story of having killed him, once they've given him a sufficiently convincing disguise to stand in with nobody noticing the switch |
| 22:14 | <Hixie> | anyone got IE9/10 available? |
| 22:14 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/ - what does the log say if you paste in <!DOCTYPE html>...<input type=number value=01><script>w(document.getElementsByTagName('input')[0].valueAsNumber)</script> ? |
| 22:15 | <zcorpan> | Hixie: hit upload |
| 22:15 | <Hixie> | done |
| 22:15 | <zcorpan> | log: undefined |
| 22:15 | <Hixie> | thanks |
| 22:16 | <zcorpan> | this was ie9 btw |
| 22:18 | <Hixie> | cool, thanks |
| 22:19 | <zcorpan> | np |
| 22:36 | <AryehGregor> | Hmm, Opera 11.10's HTML serializer seems to be broken. When will it upgrade to an HTML5 serializer? |
| 22:37 | <AryehGregor> | (specifically, it looks like <ol><li></li><ol></ol><li></ol> serializes as <ol><li><ol></ol><li></ol>) |
| 22:37 | <AryehGregor> | (which puts the <ol> inside the <li> instead of as a sibling) |
| 22:37 | <zcorpan> | doesn't ie do that as well? |
| 22:37 | <jgraham> | AryehGregor: I expect that will work once Ragnarok lands for real |
| 22:39 | <AryehGregor> | zcorpan, it does omit end tags in some cases, but it seems to get this case right (didn't test carefully). |
| 22:39 | <AryehGregor> | jgraham, . . . which means what? |
| 22:40 | <gsnedders> | when it's ready, pretty much |
| 22:40 | <jgraham> | AryehGregor: I think this is the time that I pull the Apple line about not discussing future products or services |
| 22:41 | <AryehGregor> | Aw. |
| 22:41 | <AryehGregor> | Meanie. |
| 22:41 | <jgraham> | s/Apple/Google/ maybe |
| 22:41 | <zcorpan> | AryehGregor: we'll serialize html correctly no sooner than when we parse html correctly (and likely not later either) |
| 22:41 | <jgraham> | AryehGregor: Anyway, basically what gsnedders said |
| 22:41 | <AryehGregor> | I was figuring that much, yeah. |
| 22:43 | <Hixie> | abarth: yt? |
| 22:43 | <zcorpan> | (we couldn't do it sooner because it wouldn't work right with our current DOM tree lies about where elements end) |
| 22:43 | <wilhelm_> | The codename “Ragnarok” might give a clue about the time of its arrival. (c: |
| 22:51 | <AryehGregor> | Wow, we've gotten a huge number of eleventh-hour responses to the survey. |
| 22:56 | <jgraham> | Two different Microsoft employees responded |
| 22:56 | <jgraham> | (at least) |
| 22:56 | <jgraham> | which is unusual |
| 22:59 | <AryehGregor> | Oddly, it gives the e-mail addresses of non-respondents but not respondents. |
| 23:01 | <AryehGregor> | I'm counting Adrian Bateman, Eliot Graf, Kris Krueger, Frank Olivier, and Cynthia Shelly. |
| 23:01 | <AryehGregor> | Speculation: Adrian posted the official answer, and sent out a memo to other MS people to agree with the party line. |
| 23:02 | <AryehGregor> | (Did any of them disagree?) |
| 23:02 | <Dashiva> | Are you implying a Microsoft Cabal? |
| 23:02 | <AryehGregor> | Unsurprising, since this is an individual vote rather than organizational. |
| 23:02 | <AryehGregor> | I don't think it's fair to call a publicly-traded corporation a "cabal". |
| 23:03 | <AryehGregor> | That carries some implications of secrecy that are unlikely to apply. |
| 23:05 | <Dashiva> | But then there's no need to speculate about cabal-like activities |
| 23:05 | <AryehGregor> | Well, right, granted. |
| 23:06 | <bga_> | heh in old opera 9.64 win.onmessage does not works but win.addEventListener('message' is ok |
| 23:09 | <zcorpan> | MikeSmith: the copyright notice has a link to http://www.ercim.org/ which redirects to http://www.ercim.eu/ |
| 23:09 | <zcorpan> | MikeSmith: should i change the link to http://www.ercim.eu/ ? |
| 23:11 | <jgraham> | AryehGregor: I guess the saving grace is that these "votes" are not actually votes |
| 23:11 | <AryehGregor> | There are tallies, though. |
| 23:15 | <jgraham> | In theory the analysis isn't "most votes wins" I think |
| 23:16 | <AryehGregor> | Not exactly, no, but if it has any impact at all, I expect the tallies to be a large part of it. |
| 23:17 | <AryehGregor> | I mean, almost no one *said* anything in their response other than "we like forking" or "we don't like forking". |
| 23:17 | <AryehGregor> | It's not like you can get much out of the survey other than the tallies. |
| 23:18 | <jgraham> | You could infer that there isn't consensus to adopt any of the PSIG licenses for any reasonable definition of consensus |
| 23:19 | <AryehGregor> | Well, you can get that out of the tallies. |
| 23:21 | <jgraham> | Yes, I'm not saying that the prose is very valuable |
| 23:21 | <Hixie> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=11452#c9 is fun |
| 23:22 | <jgraham> | I doubt anyone said anything that will convince anyone else |
| 23:22 | <Hixie> | AryehGregor: did anyone say "we like forking"? Not "we like the ability to fork"? I doubt anyone actually likes forking per se... |
| 23:22 | <AryehGregor> | Hixie, I was using it as shorthand. |
| 23:22 | <Hixie> | oh ok |
| 23:24 | <jgraham> | is ★ a non-BMP character? I think we have problems with non-BMP characters in file names |
| 23:26 | <zcorpan> | U+2605 - BMP |
| 23:27 | <jcranmer> | 9733 |
| 23:27 | <jcranmer> | definitely BMP |
| 23:28 | <jcranmer> | ☃ is still BMP ... o_O |
| 23:28 | <jgraham> | Oh well it must be a differnet bug then |
| 23:29 | <Hixie> | opera failed hard on that test |
| 23:29 | <Hixie> | it let me pick the file and then said "what file? there's no file here" |
| 23:32 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=12611 - clearly html-differences needs a proper review |
| 23:33 | <zcorpan> | Hixie: there is no spoon |
| 23:38 | <zcorpan> | Philip`: let me know if you make changes to the splitter |
| 23:56 | <MikeSmith> | zcorpan: it's OK to change that ERCIM URL if you want, but you it's not a requirement |
| 23:57 | <MikeSmith> | zcorpan: as far as the content, there are a few other recent changes I can think of that you should list |
| 23:58 | <MikeSmith> | e.g., new mediagroup attribute |
| 23:58 | <zcorpan> | MikeSmith: pls file bugs :) |
| 23:58 | <MikeSmith> | OK |
| 23:58 | <MikeSmith> | I was just going to ask if you wanted me to do that :) |
| 23:59 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=12223 - anyone care enough to get rel=help nuked? |