| 00:50 | <tantekc> | I'm exploring ways of "properly" or "ideally" marking up ASCII art, and there seems to be very few existing discussions of the topic. |
| 00:51 | <tantekc> | WCAG 1.0 has some techniques: http://www.w3.org/TR/WCAG10-HTML-TECHS/#ascii-art |
| 00:52 | <tantekc> | the "skip over " links always seem like a hack |
| 00:52 | <tantekc> | anyone have any data on what ATs do with <pre> marked up ASCII art? |
| 00:54 | tantekc | wonders if anyone considered making a MIME type for ASCII art, e.g. image/ascii |
| 00:54 | <hober> | text/art |
| 00:55 | <tantek> | there is this test case (for supposedly accessibly marked up ASCII art) http://www.bentoweb.org/ts/XHTML1_TestSuite3/testfiles/sc1.1.1_l1_038.html |
| 00:55 | <tantek> | linked from http://www.bentoweb.org/ts/XHTML1_TestSuite2/metadata/sc1.1.1_l1_038 |
| 00:56 | <tantek> | hober I was thinking text/art as well, until I realized that text is merely the stream format, not the general type of thing |
| 00:56 | <tantek> | image/text would be more accurate than text/image |
| 01:01 | <Hixie> | woah, xmlns has no definition of an XML namespace-well-formed internal general parsed entity |
| 01:02 | <Hixie> | bummer |
| 01:03 | <othermaciej> | tantek: what would be the right way to provide accessibility for ASCII art? |
| 01:03 | <othermaciej> | text equivalent? |
| 01:03 | <othermaciej> | <pre> would be right layout-wise but I don't think it has an obvious way to provide a text equivalent, other than ARIA |
| 01:03 | <tantek> | othermaciej - yes, a *visible* text equivalent/alt/explanation is what WCAG suggests |
| 01:03 | <tantek> | I would like a way to say <pre art> |
| 01:04 | <othermaciej> | visible - sounds good |
| 01:04 | <tantek> | (not an actual proposal) |
| 01:04 | <tantek> | just to illustrate the concept |
| 01:04 | <tantek> | I don't want ATs to attempt to speak/pronounce the ASCII art |
| 01:04 | <Hixie> | it really does appear that there's no way to use namespaces with internal general parsed entities |
| 01:04 | <othermaciej> | if the goal is to just stop AT from reading it, then <pre role=presentation> would do it |
| 01:04 | <Hixie> | how the heck do i define the XML serialisation of a DocumentFragment then |
| 01:05 | <othermaciej> | what's an internal general parsed entity? |
| 01:05 | <othermaciej> | is that a fancypants way to say document fragment? |
| 01:05 | <tantek> | othermaciej - ok I'll look at role=presentation. thanks. |
| 01:05 | <Hixie> | it a fancypants way of referring to the kind of stuff you'd find inside an element in XML |
| 01:05 | <Hixie> | i.e. the string forming the text, comments, other elements, etc in an element |
| 01:06 | <othermaciej> | would it be sufficient to define it by saying if you surround the fragment with an element, that must produce a namespace-well-formed document? |
| 01:07 | <Hixie> | yeah that's what i'm doing |
| 01:07 | <Hixie> | but that's a hack |
| 01:08 | <Hixie> | <p>For the purposes of this section, an internal general parsed entity is considered XML namespace-well-formed if a document consisting of an element whose contents are the internal general parsed entity would itself be XML namespace-well-formed.</p> |
| 01:10 | <othermaciej> | perhaps you should specify that the hypothetical element does not itself have any namespace declarations |
| 01:12 | <Hixie> | yeah |
| 01:12 | <Hixie> | <p>For the purposes of this section, an internal general parsed entity is considered XML namespace-well-formed if a document consisting of an element with no namespace declarations whose contents are the internal general parsed entity would itself be XML namespace-well-formed.</p> |
| 01:24 | <tantek> | Hixie - how can anyone expect web authors to understand something like that? |
| 01:24 | <Hixie> | web authors aren't expected to even see that |
| 01:25 | <Hixie> | it's in a class="impl" section |
| 01:25 | <Hixie> | so it would be hidden from the author view |
| 01:33 | <tantek> | ah ok, thanks. |
| 01:43 | <roc> | even if Microsoft doesn't contribute anything to HTML5, it's still really valuable for them to *say* they're contributing |
| 06:06 | <hsivonen> | for the record, Jena having six or so URL-like things is a spec problem: URI, IRI, XLink, XML system ID, etc. |
| 07:04 | <othermaciej> | why do things like XLink and XML System ID have their own syntax? |
| 07:04 | <othermaciej> | hsivonen: ^ |
| 07:04 | <othermaciej> | (curious) |
| 07:52 | <hsivonen> | othermaciej: they tried to anticipate IRIs when IRIs weren't ready, so they defined their own ways of turning a Unicode string into something you can give to an ASCII-only URI resolver |
| 07:53 | <othermaciej> | I see |
| 07:53 | <othermaciej> | fun |
| 07:54 | <hsivonen> | as for XML Schema anyURI, IIRC, they didn't get it right the first time |
| 07:54 | <hsivonen> | and not the second time |
| 07:55 | <hsivonen> | and the third attempt turned out to be permissive enough to allow any string |
| 07:56 | <othermaciej> | resource identifiers are so simple compared to stuff like HTML and HTTP, I wonder why we have all these divergent slightly different specs |
| 07:56 | <hsivonen> | I can think of 2 reasons |
| 07:57 | <hsivonen> | 1) People wanted to mark some cases as erroneous instead of making all possible strings resource identifiers |
| 07:57 | <hsivonen> | 2) The identifiers weren't Unicode from the beginning |
| 07:59 | <othermaciej> | I guess in the very beginning it wasn't clear that unicode was the answer |
| 08:05 | <izico2> | nick |
| 08:11 | <izico> | test |
| 09:18 | jgraham | resists the urge to say that RDFa isn't so much a cow path as a bunch of people pointing through a marsh and saying "let's go that way" |
| 09:19 | <annevk2> | that's not quite resisting |
| 09:19 | <annevk2> | but nice try |
| 09:19 | <annevk2> | :) |
| 09:19 | <jgraham> | Damn, foiled again |
| 09:23 | <Philip`> | Regardless of cowpathiness, the principle just says "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.", and RDFa was indeed considered (and rejected) |
| 09:24 | <Philip`> | and the whole Design Principles document doesn't become useless just because one principle in one situation did not override all other considerations |
| 09:26 | <jgraham> | Stop trying to counter my desire to construct grandisoe metaphors involing waders by pointing out that simple fact based arguments are more effective |
| 09:32 | <Philip`> | Rather than a bunch of people pointing through a marsh, perhaps the bunch of people has carefully navigated a complex path safely through the marsh, and then said "come on over here", and the hordes rush towards them in a straight line and sink, and then the bunch of people say "what's the problem? ignore the sinking hordes, we got here fine" |
| 09:36 | <Hixie> | that's quite a good metaphor |
| 09:36 | <Philip`> | jgraham: (I'm not sure I agree that facts are more effective than metaphors) |
| 09:41 | Philip` | can't work out whether RDFa is meant to be defined in terms of syntax (which Shane seems to say) or in terms of a tree model (which Manu seems to say) |
| 10:09 | <hachque> | how can i disallow the user from bolding or making new lines in a contentEditable element? |
| 10:17 | <annevk2> | hachque, by using scripting in one way or another |
| 10:17 | annevk2 | isn't sure what the best way would be for this particular issue |
| 10:18 | <mookid> | If I specify a type on a link - does the browser set the Accept header accordingly? |
| 10:19 | <mookid> | <a type="application/pdf" href="/document"> |
| 10:20 | <mookid> | is that part of the HTML5 spec? |
| 10:20 | <Philip`> | No |
| 10:20 | <Philip`> | s/ // |
| 10:21 | <Philip`> | unless I'm horribly mistaken |
| 10:21 | <mookid> | Is there any reason that could not be ammended in the spec? |
| 10:22 | <mookid> | because that is how the type attribute works for style elements |
| 10:22 | <hsivonen> | here we go again... |
| 10:23 | <mookid> | I'm not asking for a new attribute I'm asking to ammend the existing attribute |
| 10:24 | <annevk2> | hsivonen, yeah... |
| 10:24 | <Philip`> | mookid: Yes |
| 10:24 | <mookid> | yes? |
| 10:24 | <Philip`> | It would break pages that currently use <a type> and also do browser sniffing based on Accept headers |
| 10:24 | <mookid> | those pages would presumably not upgrade to HTML5 |
| 10:25 | <mookid> | and if they did they would test before they transitioned? |
| 10:25 | <Philip`> | Pages don't have a choice, because browsers aren't willing to implement separate modes for HTML4 and HTML5 |
| 10:25 | <Philip`> | All pages get processed according to HTML5's processing rules |
| 10:26 | <mookid> | what's the point in the document definition jibberish then? |
| 10:27 | <mookid> | if that is the case, I'm pretty sure any change you make will break something somewhere |
| 10:27 | <Philip`> | In HTML5, the only point is to make browsers go into standards mode instead of quirks mode |
| 10:27 | <mookid> | ok so that could be incorporated into quirks mode? |
| 10:28 | <Philip`> | Things will break, but we want to minimise that, by not making changes that we know will break things |
| 10:28 | <mookid> | ok.. |
| 10:28 | <Philip`> | Lots of current pages render in standards mode (and lots in quirks mode), and HTML5 browsers ought to be compatible with all of them |
| 10:28 | <Philip`> | Also, quirks are evil and we don't want more of them |
| 10:29 | <Hixie> | s/evil/expensive/ |
| 10:29 | <mookid> | lol.. |
| 10:29 | <mookid> | :) |
| 10:29 | <mookid> | clutching at straws here a bit eh? |
| 10:30 | <mookid> | so can someone please explain why style and script tags use the type attribute to set the accept header |
| 10:30 | <mookid> | but not in link elements |
| 10:30 | <mookid> | and where in the spec that is specified |
| 10:31 | Philip` | didn't think they did set the Accept header |
| 10:31 | <mookid> | firefox does |
| 10:31 | <mookid> | unless firebug lies |
| 10:31 | <mookid> | Hixie: you want to clear that up for me? |
| 10:32 | <mookid> | please |
| 10:32 | <Hixie> | not especially, but i would suggest testing the difference between <script src="x">, <script src="x" type="text/javascript">, and <script src="x" type="application/ecmascript"> and seeing if the type="" attribute really has any effect |
| 10:36 | <mookid> | well either way it is pretty clear that the Accept header should change depending on the semantics of the hyperlink |
| 10:37 | <Hixie> | Accept is a hold-over from a pie-in-the-sky idea that never panned out and which should be dropped altogether |
| 10:37 | <mookid> | as it stands there is no way of linking to a specific representation if the URI leverages (HTTP compliant) conneg |
| 10:37 | <mookid> | Hixie: that is your opinion |
| 10:37 | <Hixie> | indeed |
| 10:38 | <mookid> | did it ever occur to you |
| 10:38 | <mookid> | that might be because the hypermedia we have in circulation |
| 10:38 | <mookid> | doesn't provide the mechanism to leverage it |
| 10:38 | <mookid> | ? |
| 10:38 | <Hixie> | it's not because you can't leverage it, it's because it's useless |
| 10:38 | <mookid> | maybe we should just ignore PUT DELETE and OPTIONS aswell |
| 10:38 | <mookid> | nobody uses those 'in practice' either? |
| 10:39 | <mookid> | oh no wait |
| 10:39 | <Hixie> | if you have different resources, just name them different things |
| 10:39 | <mookid> | you're added them |
| 10:39 | <mookid> | that makes perfect sense. |
| 10:39 | <mookid> | Hixie: they aren't different resources |
| 10:39 | <Hixie> | that is your opinion |
| 10:39 | <mookid> | yes it is. |
| 10:39 | <Hixie> | did it ever occur to you |
| 10:39 | <mookid> | which is why an optional type attribute would do nobody any damage |
| 10:39 | <mookid> | and me a lot of good |
| 10:40 | <Hixie> | that since they aren't the same resource, they might in fact deserve different names? |
| 10:40 | <mookid> | and anyone else who's actually read and understood the HTTP spec |
| 10:40 | <mookid> | (i.e. not you) |
| 10:40 | <jgraham> | mookid: Please |
| 10:40 | <Hixie> | yeah ok i'm kinda tired of you insulting me |
| 10:40 | <Hixie> | so this conversation is over |
| 10:40 | <mookid> | yeah ok well you repeat yourself and ignore what I'm saying to you |
| 10:40 | <Hixie> | stop coming here every other week asking for this feature |
| 10:40 | <mookid> | what do you expect? |
| 10:40 | <Hixie> | it's not going to happen |
| 10:41 | <Hixie> | we have a process for adding new features: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F |
| 10:41 | <Hixie> | and no part of that process involves you insulting people on IRC |
| 10:41 | <Philip`> | I suggest insulting people on blogs instead |
| 10:41 | <mookid> | :) |
| 10:41 | <mookid> | ignoring people and not listening to them is rude |
| 10:42 | <mookid> | I don't think you understand the significance of the term 'resource' or 'representation' |
| 10:42 | <mookid> | they are important terms |
| 10:42 | <mookid> | so when you tell me two representations are two resources |
| 10:42 | <Philip`> | If you were being ignored, you wouldn't have generated so much conversation on IRC |
| 10:42 | <mookid> | and argue based on that (wrong) assumption |
| 10:42 | <Philip`> | You're just being disagreed with, which is a different issue |
| 10:42 | <mookid> | it's kind of galling Ian. |
| 10:43 | <mookid> | I'm not being ignored because deep down you know I'm right |
| 10:43 | <mookid> | :P |
| 10:43 | <mookid> | this is Ian's subjective opinion that URIs are Uniform Representation Identifiers |
| 10:43 | <mookid> | and HTTP conneg is 'useless' |
| 10:44 | <jgraham> | mookid: You have ignored the fact that everyone else disagrees with you. You have ignored the fact that you are using the wrong procedure to ask for what you want. And you seem to have ignored the life leson that insulting people doesn't make them more sympathetic to your cause |
| 10:44 | <mookid> | ok so the majority of people don't understand what a resource is |
| 10:44 | <mookid> | not many people read specs properly |
| 10:44 | <mookid> | that doesn't make me wrong |
| 10:45 | <Philip`> | It seems kind of like you're fixated on some specific HTTP syntax, and saying that it's impossible to implement the REST architecture without it, but that seems unrelated because there's not a 1:1 mapping between HTTP and REST anyway, so you can just implement the architecture with different syntax |
| 10:45 | <Philip`> | jgraham: But insulting people can be funny |
| 10:46 | <mookid> | I really didn't say anything that bad |
| 10:46 | <Philip`> | I guess that's why mpilgrim's blog is popular |
| 10:46 | <mookid> | get a grip. :/ |
| 10:47 | <mookid> | this is crazy - I can implement a prefectly valid HTTP resource with multiple representations but you won't provide the mechanism to use it properly |
| 10:47 | <mookid> | on the basis that you don't think that part of HTTP should be there |
| 10:48 | <mookid> | and 'quirks are evil' |
| 10:48 | <mookid> | it's not even like this change actually causes any issues for 'your way' |
| 10:49 | <mookid> | even if the accept header changes - why does it matter if you aren't doing HTTP conneg? |
| 10:49 | <mookid> | it doesn't. |
| 10:49 | <mookid> | infact, it'll reduce the length of the header, make the HTTP message smaller - and save some trees |
| 10:49 | <mookid> | maaaaaaan. |
| 10:50 | <Philip`> | (Hmm, even http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3_2_7 doesn't seem to like Accept much - "In short, a server is rarely able to make effective use of preemptive negotiation") |
| 10:52 | <mookid> | the main barrier to that is lack of effective hypermedia |
| 10:52 | <Philip`> | I don't think HTTP messages are made out of trees, unless you're using a very outdated protocol |
| 10:52 | <mookid> | no but HTTP messages are routed and processed |
| 10:52 | <mookid> | if they're smaller less energy will be used to transmit them |
| 10:54 | <mookid> | that's irrelevant anyway - it's not an incompatible change, you have quirks mode incase some muppet is doing something super weird with the accept header |
| 10:55 | <mookid> | the *only* reason I've been given so far is Ian's opinion that HTTP coneg is 'wrong' and 'doesnt work' |
| 10:55 | <mookid> | which he justifies by clearly misinterpreting the meaning of the term 'resource' |
| 10:55 | <Philip`> | It takes like a microsecond for a router to process a hundred bytes of HTTP header, and if you have a trillion HTTP requests per day then that's only 10 days of processing time, so it's like 10 computers dedicated to processing the extra header for the entire world |
| 10:55 | <Philip`> | which isn't much |
| 10:56 | <mookid> | that wasn't a serious point. |
| 10:56 | <Philip`> | It's more interesting than serious points, though |
| 10:56 | <mookid> | yeah well |
| 10:57 | <mookid> | don't think there's any doubt about that here |
| 10:57 | Philip` | wonders how many HTTP requests per day there are in the world |
| 10:57 | <mookid> | "resources are made of cheese - you're argument is invalid" |
| 10:58 | <mookid> | oh ok thanks Ian |
| 10:58 | <mookid> | Protector of Internet Citizens from the evils of HTTP Application develoeprs |
| 10:59 | <mookid> | I think I'll file a bug report in the spec where you're adding PUT/DELETE to the method attribute - it's not used in practice so it's broken |
| 10:59 | <mookid> | when is it being added? |
| 10:59 | <mookid> | why^ |
| 11:00 | <Philip`> | Hmm, http://www.thepicky.com/software/google-handles-235-million-searches-per-day/ says Google only has hundreds of millions of searches per day, which is billions of requests, and I suppose it's reasonable to imagine people do hundreds or thousands of requests before searching again |
| 11:02 | <mookid> | http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-09.html#accept |
| 11:02 | <erlehmann> | Philip`, mandatory data retention laws may solve this question as soon as a sizable set leaks |
| 11:02 | <Lachy> | I finally got approval for TPAC. :-) |
| 11:03 | <Lachy> | I'll be attending |
| 11:03 | <Hixie> | yay |
| 11:03 | <Philip`> | erlehmann: Okay, I'll watch the torrent sites for a file with a petabyte of leaked daily internet traffic |
| 11:03 | <Hixie> | i mean, i'm sorry for you that you'll be there, but i'm glad for me that you'll be there :-P |
| 11:03 | <erlehmann> | Philip`, data retention is only connections, not content, so … |
| 11:04 | <Lachy> | haha :-D |
| 11:04 | <mookid> | Hixie: I apologise if I offended you by inferring you didn't understand the HTTP spec. Do you want to first have a discussion on wha tthe meaning of 'resource' is? |
| 11:05 | <mookid> | I didn't intend to offend you btw, I just assumed that was a correct accusation given your interpretation of 'resource' |
| 11:06 | <Philip`> | erlehmann: That won't help answer my question then, if it doesn't keep enough content to identify HTTP requests :-( |
| 11:06 | <Philip`> | (including in keepalive sessions) |
| 11:07 | <erlehmann> | i have not read the data retention specs, so i'm afraid i cannot answer that |
| 11:08 | <Philip`> | Maybe I could just ask the internet to use my computer as a proxy for a day, so I can measure the traffic accurately |
| 11:12 | <erlehmann> | I hereby pronounce tomorrow, the 23.09.2009 the first annuary Philip Taylor Proxy Day \o/ |
| 11:13 | <erlehmann> | The cabal sure can help you with that, Philip` ;) |
| 11:13 | <hsivonen> | Hixie: has an "unselectable" attribute been considered for inclusion in HTML5? |
| 11:13 | <Hixie> | no |
| 11:13 | <Hixie> | not as far as i recall |
| 11:13 | <Philip`> | erlehmann: Excellent! |
| 11:13 | <erlehmann> | hsivonen, unse-what ? you mean not being able to get focus? |
| 11:14 | <Philip`> | erlehmann: I'll tell you my IP address tomorrow (it's dynamic so I'm not sure what it'll be) |
| 11:14 | <hsivonen> | erlehmann: I gather it's an IE thing for restricting contenteditable and/or designmode |
| 11:17 | <mookid> | I'm pretty sure if there was a floor in my reasoning you wouldn't hesitate to point it out :) |
| 11:18 | erlehmann | snickers with glee |
| 11:18 | <Philip`> | Hixie: "The HTML syntax does not support namespace declarations, even in foreign elements" - doesn't it support xmlns:xlink in foreign elements? |
| 11:19 | <Philip`> | which counts as (partial) support for namespace declarations |
| 11:19 | <hsivonen> | Philip`: it supports creating a namespace declaration but it doesn't support making the declaration affect processing in the parser |
| 11:19 | <Philip`> | plus plain xmlns in foreign elements, which is also a namespace declaration |
| 11:20 | <hsivonen> | so the cause and effect are reversed compared to XML |
| 11:20 | <Philip`> | hsivonen: That sounds like it still supports (some) namespace declarations, it just doesn't support the use of declared namespaces |
| 11:20 | <hsivonen> | Philip`: indeed |
| 11:20 | <hsivonen> | three declarations to be exact |
| 11:34 | <Lachy> | Hixie, this bug isn't fixed, despite you marking it resolved http://www.w3.org/Bugs/Public/show_bug.cgi?id=7506 |
| 11:34 | <Hixie> | Philip`: it doesn't support namespace declarations in any meanginful sense |
| 11:35 | <Lachy> | Hixie, I wanted you to update the spec where it says "The presence of an obsolete permitted DOCTYPE." in the implementation requirements of section 12.1.1 Warnings for obsolete but conforming features. |
| 11:35 | <Hixie> | oh, in the implementation section |
| 11:35 | <Lachy> | I suggest it be ammended to say something like "The presence of an obsolete permitted DOCTYPE. (HTML only)" |
| 11:36 | <Hixie> | ok, doing that now |
| 11:36 | <Hixie> | sorry i thought you meant the previous section |
| 11:50 | <mookid> | is there going to be an API for doing javascript includes? |
| 11:51 | <mookid> | so you can have a one line script tag that boostraps a page |
| 11:52 | <Creap> | http://www.spicywebdesign.com/first-html-example-page-html-5-code/ |
| 11:52 | <Creap> | heh |
| 11:58 | <erlehmann_> | Creap, wat |
| 11:59 | <Creap> | I wonder how you'd come to the conclusion that you can make up your own elements |
| 12:10 | <annevk2> | so I just read up on the RDFa discussion and was a bit surprised that we're still not passed xmlns being in a namespace in XML and not in HTML not being considered any kind of issue phase |
| 12:15 | <Hixie> | hah, bug 7594's section is #_firebugConsole |
| 12:26 | <Philip`> | Hixie: The syntax supports (some) namespace declarations in as meaningful a way as XML does, by parsing them into the same DOM |
| 12:26 | <Hixie> | i guess |
| 12:27 | <Hixie> | how would you phrase it? |
| 12:28 | <jgraham> | The key difference is that HTML doesn't support arbitary namespace declarations |
| 12:28 | <jgraham> | I guess |
| 12:29 | <Philip`> | That's like asking me for constructive comments, which is not fair |
| 12:29 | <jgraham> | But I don't really know which bit of the spec you are talking about |
| 12:29 | <Lachy> | Hixie, you're making too many checkins! I barely have enough time to reload and review the changes before the notification pops up telling me to do it again. |
| 12:30 | <Hixie> | hehe |
| 12:32 | <Philip`> | Hixie: I might just phrase it exactly like how it's phrased now, and tell people to not be pointlessly pedantic about it |
| 12:33 | <Hixie> | works for me! |
| 12:46 | <Hixie> | well, we're back to e-mails being the highest line, so i guess tomorrow i'll return to bashing on them |
| 12:46 | <Hixie> | nn |
| 12:49 | <annevk2> | we need a higher resolution graph to actually see the details of recent months :) |
| 12:49 | <annevk2> | on http://www.whatwg.org/issues/data.html that is |
| 12:50 | <Philip`> | annevk2: Use Safari and increase your desktop scaling factor and then it'll be higher resolution :-) |
| 12:50 | <zcorpan> | annevk2: doesn't http://www.whatwg.org/issues/data.html?period=1 work? |
| 12:51 | <hsivonen> | zcorpan: cool. thanks |
| 12:52 | <hsivonen> | the whole point of vector graphics in defeated when one zooms the page in Firefox |
| 12:52 | <erlehmann> | D; |
| 12:52 | <hsivonen> | (yes, I realize it's not really vector graphics) |
| 12:52 | hsivonen | thinks the graph should be in SVG |
| 12:52 | <annevk2> | zcorpan, ah, the feature is already present |
| 12:53 | <annevk2> | hsivonen, or Firefox should get a better zooming algo |
| 12:54 | <hsivonen> | annevk2: a better zooming algo doesn't help here |
| 12:54 | <hsivonen> | annevk2: either all canvases should have a hires backing buffer in case the user zooms |
| 12:55 | <hsivonen> | annevk2: or there should be a way to asks the page to repaint canvas to a new hires backing buffer after zooming |
| 12:55 | <Philip`> | Or you should use SVG if you want scalable vector graphics |
| 12:56 | <hsivonen> | do we have a non-game use case for <canvas> yet that shouldn't have been addressed by using a non-<canvas> solution? |
| 12:57 | <ROBOd> | hello everyone |
| 12:57 | <hsivonen> | hello |
| 12:57 | <zcorpan> | it seems Hixie has beaten the high score on revision activity last week |
| 12:57 | <ROBOd> | is there any user agent which implements <style scoped>? |
| 12:57 | <Philip`> | hsivonen: Maybe the Paint clone |
| 12:57 | <zcorpan> | v.nu implements it i think |
| 12:57 | <Philip`> | and things that apply custom JS filters to images/videos |
| 12:58 | <zcorpan> | though maybe it's not the kind if user agent you're looking for :) |
| 12:58 | <ROBOd> | zcorpan: indeed |
| 12:58 | <zcorpan> | i don't think any browser has implemented it |
| 12:58 | <ROBOd> | i am thinking more along the lines of gecko, webkit, presto or even trident |
| 12:59 | <ROBOd> | zcorpan: do you know if there are plans for it? like in dev builds of gecko/webkit/etc |
| 13:00 | <zcorpan> | don't know |
| 13:00 | <ROBOd> | oky, thanks anyway ;) |
| 13:01 | <zcorpan> | if you want it, file bugs |
| 13:02 | <ROBOd> | hm, not really sure if it fits the use-case scenario i want it for |
| 13:05 | zcorpan | notes that http://www.whatwg.org/issues/data.html is invalid after scripts have run |
| 13:10 | <mookid> | Hixie: am I allowed to comment on that bug? |
| 13:13 | <Lachy> | mookid, yes. Anyone is allowed to |
| 13:40 | <mitsuhiko> | heyho everybody |
| 13:40 | <mitsuhiko> | does anyone know a html5 parser written in c that is reusable? |
| 13:41 | <mitsuhiko> | ideally one that can emit errors and warnings and as such used for validation |
| 13:41 | <mookid> | err |
| 13:41 | <mookid> | how do you determine if a bug is resolved or not |
| 13:41 | <mookid> | I didn't even get a chance to respond to that and it's already closed.. |
| 13:41 | <mookid> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=7697 |
| 13:42 | <annevk2> | mitsuhiko, there's no standalone c implementation yet |
| 13:42 | <mitsuhiko> | annevk2: is anyone working on that? |
| 13:42 | <mitsuhiko> | and are there estimations about how complex that would be? |
| 13:42 | <hsivonen> | there's hubbub, but I'm not sure how up-to-date it is |
| 13:43 | <hsivonen> | mitsuhiko: I'm working on a C++ implementation that is Gecko-specific |
| 13:43 | <mitsuhiko> | basically i would love to see a live-html5 validator for firefox |
| 13:43 | <mitsuhiko> | there is a sgml validator already, but that one of course does not do the trick with html5 :) |
| 13:43 | <annevk2> | mitsuhiko, did you look into Validator.nu? |
| 13:44 | <mitsuhiko> | annevk2: that is quite complex to setup and requires java as far as i know |
| 13:44 | <mookid> | how do you guys decide whether or not an issue in the bug tracking system should be closed or not? |
| 13:44 | <mitsuhiko> | and sending http requests there for everything does not sound like a good idea |
| 13:44 | <mitsuhiko> | i'm already using validator.nu as part of my testsuite though |
| 13:44 | <hsivonen> | mitsuhiko: I plan to add parse error reporting eventually, but adding error reporting is at the bottom of the priority list, because it isn't needed for parity with the old parser |
| 13:44 | <mitsuhiko> | hsivonen: makes sense |
| 13:45 | <hsivonen> | the bugzilla entry is https://bugzilla.mozilla.org/show_bug.cgi?id=512229 |
| 13:45 | <hsivonen> | also that stuff is localization-sensitive and so forth |
| 13:46 | <annevk2> | mitsuhiko, yeah, though hsivonen wrote a To-Mozilla-C translator of some sorts |
| 13:46 | <mitsuhiko> | hsivonen: i will monitor that |
| 13:46 | <annevk2> | mitsuhiko, and the idea is to use that new parser in Gecko in due course |
| 13:47 | <mitsuhiko> | isn't that one already in the nightlies? |
| 13:47 | <mitsuhiko> | at least there is a setting to enable a html5 parser |
| 13:47 | <hsivonen> | mitsuhiko: yes |
| 13:47 | <mitsuhiko> | guess i looked at that one yesterday then |
| 13:47 | <hsivonen> | mitsuhiko: the ground work of making tokenizer error reporting Gecko-friendly has been done but doesn't have Java-to-C++ translations support yet |
| 13:47 | <mitsuhiko> | unfortunately mozilla code still makes my eyes bleed. i don't understand that com stuff at all :( |
| 13:48 | <hsivonen> | mitsuhiko: the ground work for tree builder error reporting isn't done |
| 13:48 | <mitsuhiko> | yeah. saw that |
| 13:48 | <mitsuhiko> | it's not doing anything with errors currently |
| 13:50 | <mitsuhiko> | the sgml validator extension for firefox was the only way i could keep the pages validated, because i just don't have the time to submit all pages to an external validator website |
| 13:53 | <Philip`> | You could have an extension that automatically submits them to an external site and gives you the result almost immediately - would that be adequate? |
| 13:55 | <hsivonen> | mitsuhiko: having just an HTML5 parser doesn't give you validation |
| 13:56 | <mitsuhiko> | hsivonen: yes, but it's a good start for writing a validator |
| 13:57 | <mitsuhiko> | Philip`: would require a network connection and would slow down the whole thing a lot |
| 13:57 | <hsivonen> | mitsuhiko: I suggest using http://code.google.com/p/jsrelaxngvalidator/ with the schemas Validator.nu uses and porting the rest over using GWT |
| 14:36 | <annevk2> | http://groups.google.com/group/openweb-group is the openweb.org thing I mentioned a while back |
| 14:37 | annevk2 | found the reference again in his email |
| 14:37 | <Dashiva> | http://lists.w3.org/Archives/Public/www-archive/2009Sep/0056.html |
| 14:37 | <Dashiva> | What's going on there? |
| 14:47 | <Philip`> | Dashiva: Given that it says "shaped regions for text", maybe the idea is that authors really think it's important to write pages with text wrapped inside a triangle that is morphing into a balloon over time in synchronisation with a video |
| 15:03 | annevk2 | starts noble attempt to clean up <basefont> mess further: https://bugzilla.mozilla.org/show_bug.cgi?id=518110 & https://bugs.webkit.org/show_bug.cgi?id=29641 |
| 15:05 | <zcorpan> | annevk2: why? |
| 15:06 | <TabAtkins> | Mornin', all. (Day 11 of no internet at home ;_;) |
| 15:08 | <Philip`> | (If it's bad enough to make commas fall out of your eyes, surely it'd be worth finding some alternative access mechanism :-) ) |
| 15:11 | <TabAtkins> | Still not worth it. I'm absolutely certain that the day I buy a cellular dongle they will repair the line. |
| 15:11 | <beowulf> | if that's within 30 days of buying the dongle, you can return the dongle, no? |
| 15:12 | <TabAtkins> | Not if I've opened it. |
| 15:12 | <beowulf> | I think you can return it even if you've opened it, but meh |
| 15:13 | <TabAtkins> | omg so many emails. This is the real tragedy of not having home internet - I don't get to clear my inbox every few hours. |
| 15:15 | <Philip`> | Indeed, missing out on days of public-html mail is a tragedy comparable in scope to Hamlet |
| 15:16 | <beowulf> | :) |
| 15:19 | <annevk2> | zcorpan, because it bugs me? |
| 15:20 | <annevk2> | future generations blaming us for not cleaning up enough of the mess of our elders haunts me :) |
| 15:21 | <Philip`> | They're much more likely to blame us for the new messes we're creating |
| 15:21 | <Philip`> | and in those cases there's nobody to shift the blame to |
| 15:23 | <mitsuhiko> | does html5 allow empty <ul>/<ol> tags? |
| 15:23 | <annevk2> | yes |
| 15:23 | <mitsuhiko> | \o/ |
| 15:23 | <annevk2> | Philip`, those are harder to fix for us because we do not have the benefit of hindsight |
| 15:24 | <Philip`> | annevk2: Experience suggests that won't stop them blaming us for it |
| 15:25 | <Philip`> | so it's even more important to try to fix them :-) |
| 15:31 | <zcorpan> | why are light dimmers noisy? |
| 15:31 | <zcorpan> | that's something that bugs me |
| 15:36 | <zcorpan> | hmm, why can't we use data: urls for workers |
| 15:37 | <TabAtkins> | Do data urls have an origin? |
| 15:37 | <Philip`> | zcorpan: They've got to do something with the photons that are not coming out of the light, so the dimmers have a little pool of black ink for the spare photons to fall into, which causes the noise |
| 15:39 | <zcorpan> | Philip`: still, the noise bugs me and i'd like it if someone invented a silent dimmer |
| 15:39 | <Philip`> | Maybe they should make a dimmer that controls two lightbulbs in opposition, so one is bright while the other is dark |
| 15:39 | <Philip`> | and then there wouldn't be the problem with the spare photons |
| 15:40 | <Philip`> | (Is it the dimmer itself that's noisy, or the bulb?) |
| 15:40 | <zcorpan> | TabAtkins: yeah, they do |
| 15:41 | <TabAtkins> | zcorpan: Interesting. Is it the originating page? Everything I know about data urls I learned from wikipedia. |
| 15:41 | <zcorpan> | Philip`: the dimmer |
| 15:42 | <Philip`> | zcorpan: Okay - not sure what would actually cause that |
| 15:42 | <zcorpan> | TabAtkins: http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin-0 |
| 15:42 | Philip` | doesn't think he's ever experienced that problem himself |
| 15:43 | <zcorpan> | Philip`: i've had several dimmers and all of them have been noisy |
| 15:44 | <TabAtkins> | zcorpan: Ah, so the origin is just a guid, if I'm reading correctly. Makes sense. |
| 15:44 | <zcorpan> | TabAtkins: yeah |
| 15:44 | <zcorpan> | but i don't want to have to use another file for workers |
| 15:45 | <zcorpan> | maybe i can put the script in a comment at the top of the html and use new Worker('') |
| 15:45 | <TabAtkins> | Is workers a separate spec now? |
| 15:45 | TabAtkins | is trying to find it. |
| 15:45 | <zcorpan> | always been |
| 15:45 | <zcorpan> | whatwg.org/ww |
| 15:46 | <TabAtkins> | Man, I'm all kinds of behind. I've been keeping up with workers, but only in an abstract sense - I don't expect to be using them for a while still. |
| 15:47 | <TabAtkins> | Oh, so it's what I thought - the restriction on data: workers is indeed origin-based. |
| 15:47 | <zcorpan> | yes |
| 15:47 | <TabAtkins> | Ok, so now I'm caught up to your question. ^_^ |
| 15:48 | <TabAtkins> | I'd like a data: worker too. While the origin is officially different, in practice it should have the same level of trust as the page itself. |
| 15:49 | <zcorpan> | yeah |
| 15:49 | <zcorpan> | or maybe... |
| 15:50 | <zcorpan> | <script type=text/x-worker id=worker>...</script> <script>var w = new Worker('#worker')</script> |
| 15:50 | <TabAtkins> | Interesting. |
| 15:50 | <TabAtkins> | Can you do an importScripts with a data url? |
| 15:51 | TabAtkins | isn't sure that would be useful. |
| 15:51 | <Philip`> | If data URLs have a unique origin, does that mean ctx.drawImage(Image with src = canvas.toDataURL()) should now mark the canvas as tainted? |
| 15:51 | Philip` | doesn't remember what data URL origins were defined to be when he last checked this, and concluded that it shouldn't taint the canvas |
| 15:52 | <zcorpan> | Philip`: no |
| 15:52 | <zcorpan> | Philip`: origin for images and documents special-case data: |
| 15:52 | <Philip`> | Oh, okay |
| 15:59 | <brucel> | Hey cabal: a repeat question and a[nother] stupid question. |
| 16:00 | <brucel> | 1: is there a friendly explanationn of the new content types anywhere (am not relishing trying to write one for html5doctor) |
| 16:00 | <brucel> | 2: got an example of svg in html5 that works and is valid? I want to reassure some people that you haven't killed SVG |
| 16:01 | <Philip`> | Do you mean all new content-types defined/used by HTML5, or just text/html vs application/xhtml+xml? |
| 16:02 | <brucel> | Philip had an email asking for explanation of flow, interactive, embedded etc |
| 16:03 | <Philip`> | brucel: http://hsivonen.iki.fi/test/svg-and-mathml-in-html.html has SVG in text/html, and if the validator says it's invalid then hsivonen should fix something |
| 16:03 | <Philip`> | brucel: Oh, I thought you meant HTTP content-types |
| 16:03 | <Philip`> | rather than what HTML5 seemingly calls content models |
| 16:04 | <Philip`> | Does http://www.whatwg.org/specs/web-apps/current-work/multipage/images/content-venn.svg not make it trivially obvious? |
| 16:04 | <Philip`> | Clearly content models are like an amoeba |
| 16:05 | <Philip`> | brucel: (Any SVG in application/xhtml+xml should be just as valid as it always has been) |
| 16:05 | <brucel> | Philip, well, of course it's trivially obvious to *me* (ahem...) |
| 16:06 | <brucel> | Philip, but SVG in an html5 doc , served as text/html |
| 16:10 | <hsivonen> | brucel: Validator.nu says SVG-in-text/html is invalid in order to discourage authors from using it before browsers are ready. |
| 16:11 | <hsivonen> | brucel: yes, it would be better to have a message that says so instead of having a message that says SVG isn't allowed |
| 16:11 | <hsivonen> | brucel: (and also, it's spec-wise proper for a validator to say it's invalid if the validator developer opted not to invoke the "other relevant specifications" clause for SVG) |
| 16:11 | <brucel> | hsivonen wasn't gonna nag you; am simply looking for an example of how to do it. Do I just take my conforming SVG (without doctype) and put it into an html5 page? |
| 16:13 | <hsivonen> | brucel: as it stands, you also need to zap the foreign-namespace cruft from Inkscape or Illustrator (which is totally inconvenient) |
| 16:13 | <hsivonen> | brucel: and zap Illustrator-emitted namespace-URIs-as-entities |
| 16:17 | <Philip`> | You can always put the SVG in an <object> if you want |
| 16:17 | <Philip`> | which is probably the best approach unless you have a good reason for wanting it to be inline |
| 16:25 | <brucel> | Ta all. Not sure I'm any the wiser about an html5 doc with svg inside it, tho |
| 16:35 | <Philip`> | Hmm, I think html5lib might have broken pyRdfa |
| 16:36 | <Philip`> | because it seems pyRdfa no longer recognises xmlns:* attributes |
| 16:40 | <Philip`> | because html5lib passes it xmlnsU0003A attributes instead |
| 16:41 | <gsnedders> | With what treebuilder? |
| 16:43 | Philip` | shrugs |
| 16:44 | <Philip`> | parser = html5lib.HTMLParser(tree=treebuilders.getTreeBuilder("dom")) |
| 16:44 | <zcorpan> | does html5lib apply the coercion rules by default? |
| 16:44 | <gsnedders> | IIRC no |
| 16:45 | <jgraham> | In DOM I think it does |
| 16:45 | <jgraham> | For some reason |
| 16:45 | <jgraham> | Possibly because of gsnedders |
| 16:45 | <gsnedders> | minidom b0rkedness, I bet |
| 16:45 | gsnedders | claims innocence |
| 16:45 | <jgraham> | That might be the wrong thing to do |
| 16:47 | <gsnedders> | jgraham: How many test failures do you get? |
| 16:48 | <jgraham> | Me? None, I;m not running the tests right now |
| 16:48 | <gsnedders> | jgraham: When you run them… |
| 16:48 | <gsnedders> | jgraham: And with what tree-builders/walkers? |
| 16:49 | <jgraham> | gsnedders: I can't actually run all the tests on this computer because it has too new a simplejson |
| 16:49 | <gsnedders> | We need to fix that somehow. |
| 16:49 | <jgraham> | I could just run the parser tests if that would help |
| 16:50 | <TabAtkins> | Man, why do people keep letting Reschke derail technical conversations with arguments about process? |
| 16:51 | <gsnedders> | test_parser.py gives no output here :\ |
| 16:52 | <jgraham> | gsnedders: I get 20 failures from test_parser.py |
| 16:52 | <jgraham> | But I don't have bs installed or I would get more |
| 16:53 | <Philip`> | TabAtkins: Maybe we need to discuss a process to stop people from talking about process |
| 16:53 | <TabAtkins> | Philip`, don't even dare suggest that. |
| 16:54 | <jgraham> | gsnedders: So that is 5 tests that fail. One I think might be a wrong test. One seems to be a change to <xmp> parsing. The rest (I think) are to do with whitespace in the AAA |
| 16:54 | <gsnedders> | jgraham: I don't have BS either |
| 16:55 | <gsnedders> | http://pastebin.ca/1575346 |
| 16:57 | <gsnedders> | jgraham: I get 20 with simpletree cElementTree ElementTree lxml DOM |
| 16:57 | <jgraham> | gsnedders: Yeah I'm not sure what the deal is there. I *think* it's generic setuptools suckiness |
| 16:57 | <jgraham> | I tend to just delete the systemwide copy |
| 16:58 | <jgraham> | If there is a proper solution, I would like to know what it is... |
| 16:58 | <jgraham> | gsnedders: OK, same as me. And I guess that is 4 actual test fails |
| 16:58 | <gsnedders> | jgraham: What do you get with treewalkers? |
| 16:59 | <jgraham> | The test <body><frame></frame></frame><frameset><frame><frameset><frame></frameset><noframes></frameset><noframes> I remember thinking had a bug |
| 16:59 | <jgraham> | Do you have a moment to check? |
| 16:59 | <gsnedders> | Not really |
| 17:00 | <gsnedders> | Ah, it's the tokenizer tests where I get tons of failures |
| 17:00 | <gsnedders> | Oh well, back to things I actually need to do |
| 17:01 | <jgraham> | gsnedders: I get a bunch of fails (50) but 20 of those are the same fails as the treebuilder tests |
| 17:01 | <jgraham> | and the rest look to be DOM using magic encoding |
| 17:01 | <gsnedders> | jgraham: For which tree walker? I get 24 |
| 17:01 | <gsnedders> | *which? |
| 17:02 | <jgraham> | Er, the same ones that I had treebuilders for |
| 17:02 | <jgraham> | + genshi |
| 17:02 | <gsnedders> | For runtests, I get FAILED (failures=153, errors=1) |
| 17:02 | <gsnedders> | +PullDOM? |
| 17:03 | <jgraham> | YEs |
| 17:03 | <jgraham> | (actually there are a bunch of fails with Genshi too) |
| 17:04 | <jgraham> | gsnedders: Using an old simplejson? |
| 17:04 | <gsnedders> | jgraham: Yeah |
| 17:04 | <jgraham> | gsnedders: Also, what else fails? I think I have some fixes at home... |
| 17:06 | <gsnedders> | We could go for U[0-9A-F]{6} within JSON for surrogates char to get it working… |
| 17:07 | <jgraham> | gsnedders: Talk to hsivonen. I don't want to break his test harness |
| 17:07 | <gsnedders> | jgraham: That was my conclusion last time I thought about it. |
| 17:07 | <jgraham> | So I will do basically whatever he is happy with since almost anything is easier to do in Python than in Java |
| 17:08 | <gsnedders> | http://pastebin.ca/1575365 |
| 17:08 | gsnedders | grumbles something about the PHP impl passing all the tests |
| 17:09 | <gsnedders> | Surely if you can pass them in PHP, it should be easier in Python :P |
| 17:09 | <jgraham> | gsnedders: Don't they disable the mixed namespace stuff or something? |
| 17:09 | <jgraham> | Also, we have more tests |
| 17:09 | <gsnedders> | (Well, we fail some invalid UTF-8 tests for the inputstream, but that's all) |
| 17:09 | <jgraham> | (probably) |
| 17:10 | <gsnedders> | jgraham: I think that's all enabled now. |
| 17:11 | <gsnedders> | Yeah, mixed namespace stuff works |
| 17:12 | <jgraham> | gsnedders: It seems like there aren't actually many issues. They just need to be fixed |
| 17:13 | <jgraham> | Then the option to not namespace HTML elements needs to work |
| 17:13 | <jgraham> | Those are the showstoppers |
| 17:13 | <gsnedders> | We need something good to parse into in PHP. |
| 17:26 | <Philip`> | Oh, hmm, I was using the latest SVN revision of html5lib |
| 17:27 | <Philip`> | Wonder if that makes much difference... |
| 17:28 | <jgraham> | Philip`: I think it does. I recall there was some reason to change the DOM stuff but I entirely forget what it was |
| 17:29 | jgraham | wonders if it was minidom or pyxdom |
| 17:29 | <jgraham> | or something else I guess |
| 17:33 | <Philip`> | Grabbing the hg version would be easier if my wireless connection didn't drop after about three seconds of sustained usage, and/or if hg clone automatically resumed instead of freezing when the network connection drops |
| 17:40 | <miketaylr> | in html5, can and id begin with an underscore? i.e., "_foo"? |
| 17:42 | <miketaylr> | all i see in the spec is "The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character. The value must not contain any space characters." |
| 17:43 | <miketaylr> | but i might be missing something |
| 17:43 | <Lachy> | miketaylr, I don't believe there are any special restrictions on what the ID attribute can contain |
| 17:44 | <miketaylr> | Lachy: ok, thanks. |
| 17:44 | <miketaylr> | i know that was verboten in html4, just double checking. |
| 17:44 | <miketaylr> | since "_foo" still validates as html4, but the spec clearly says it must begin with a letter. |
| 17:45 | <sicking> | annevk2: you coming to TPAC? |
| 17:46 | <Lachy> | sicking, yes, both annevk2 and I are |
| 17:46 | <sicking> | Lachy: Anne wasn't listed as attending the webapps last i looked. I think |
| 17:46 | <Lachy> | we only got given approval to go earlier today |
| 17:47 | <Lachy> | do we have to sign up somewhere to say that we're going to the webapps meeting? |
| 17:47 | <sicking> | you have to register for TPAC. As you're doing that the page will ask you what you're attending each day |
| 17:48 | <annevk2> | sicking, registered myself today |
| 17:48 | <Lachy> | ok |
| 17:49 | <sicking> | Lachy: also, just today? That's really late. You should get efficient, like swedes: http://www.osoyou.com/items/14780.publisha |
| 17:49 | <annevk2> | sicking, management was a bit slow |
| 17:50 | <sicking> | annevk2: ah, you're listed now |
| 17:57 | <Philip`> | miketaylr: In HTML4 that's just a limitation of the DTD validation technology |
| 17:57 | <miketaylr> | Philip`: ah. that makes sense now. thanks. |
| 17:58 | <Philip`> | validator.nu does a better job for HTML5, since it can check the content of attribute values |
| 17:58 | <Philip`> | (but HTML5 removes the unnecessary and frequently-ignored restrictions on id values) |
| 18:00 | <sicking> | Lachy: btw, wasn't there talk about a level 2 selectors spec that specified a matchesSelector function? |
| 18:01 | <sicking> | Lachy: i think we're going to implement that for next version of firefox, would be nice to do it without prefixing it with 'moz' |
| 18:02 | <tantek> | sicking if you mean the W3C Selectors spec, there have been many :matches like proposals, but none of them have made it into a working draft AFAIK |
| 18:02 | <tantek> | due to implementation performance problem (expectations) |
| 18:02 | <sicking> | tantek: no, i mean a spec that specifies an API where you can test is a node matches a selector |
| 18:02 | <sicking> | tantek: a scripting API that is |
| 18:02 | <tantek> | oh SelectorsOM |
| 18:02 | <sicking> | right |
| 18:03 | <Lachy> | sicking, yeah, it's being planned. I intend to begin working on that spec soon |
| 18:03 | <tantek> | Lachy, which spec? Is it a DOM spec or a CSS spec? |
| 18:03 | <sicking> | (not sure if "OM" is correct, since we don't expose the internals of a parsed selector, but) |
| 18:04 | <sicking> | Lachy: i think we might have a implementation and a test suite available already :) |
| 18:04 | <Philip`> | Hmm, what happens if (for example) we define an API that can play music in the style of various composers, so you call .bach() and .handel() and .mozart() etc, and then Mozilla wants a vendor-specific extension to play music like somebody called Art? |
| 18:04 | <Lachy> | tantek, Selectors API 2 |
| 18:04 | <sicking> | Lachy: https://bugzilla.mozilla.org/show_bug.cgi?id=518003 |
| 18:04 | <tantek> | Lachy, wondering which working group is doing it (CSS WG, HTML WG, DOM WG?) |
| 18:05 | <Lachy> | webapps |
| 18:05 | <sicking> | Philip`: haha |
| 18:05 | <sicking> | Philip`: funny thing is that when i read 'mozart' i was reading it as moz-art :) |
| 18:05 | <sicking> | tantek: DOM WG is dead, long live WebApps WG |
| 18:06 | <sicking> | Philip`: but to answer your question, we'd call it mozArt() |
| 18:06 | <tantek> | thanks for the update sicking. somehow I knew that and had somehow forgotten. |
| 18:07 | <Lachy> | sicking, this is the bug I'm using to track the feature for the spec http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865 |
| 18:08 | <Lachy> | sicking, is the Moz implementation essentially compatible with the JQuery impl.? |
| 18:08 | <Lachy> | http://docs.jquery.com/Traversing/is#expr |
| 18:09 | <sicking> | Lachy: will look |
| 18:09 | <sicking> | Lachy: what does jquery do when .is is called on a textnode? |
| 18:10 | <Lachy> | I don't know. Ask JohnResig |
| 18:10 | <Lachy> | sicking, which interfaces is the API implemented on? |
| 18:10 | <Lachy> | Is it just the Element interface? |
| 18:10 | <sicking> | "returns true, if at least one element of the selection fits the given expression". So i guess it can be called on some set in jquery |
| 18:10 | <Lachy> | I hope it's not Node.matchesSelector |
| 18:11 | <sicking> | the current patch just exposes it on elements |
| 18:11 | <Lachy> | good |
| 18:11 | <Lachy> | that makes things sensible |
| 18:11 | <Lachy> | how does it work with pseudo-elemenets? |
| 18:11 | <sicking> | *possibly* you could expose it on textnodes/comments/etc and have it always return false |
| 18:12 | <sicking> | Lachy: works the same way querySelectorAll does. However that is |
| 18:12 | <Lachy> | that would be silly, since querySelector() is only on Document, Element and DocumentFragment |
| 18:12 | <Lachy> | ok, that's good |
| 18:12 | <Lachy> | seems fairly simple to define then |
| 18:12 | <sicking> | there was also talk about exposing it on NodeList |
| 18:12 | <Lachy> | yeah, that's a separate issue |
| 18:13 | <sicking> | and have it return a filtered nodelist |
| 18:13 | <sicking> | dunno what it should be called there though |
| 18:13 | <Lachy> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864 |
| 18:13 | <Lachy> | I was just going to define NodeList.querySelectorAll() |
| 18:13 | <sicking> | Lachy: that looks different |
| 18:13 | <Lachy> | Not sure if we'd need NodeList.querySelector() too |
| 18:14 | <Lachy> | how? |
| 18:14 | <sicking> | Lachy: i was talking abotu NodeList.matchesSelector |
| 18:14 | <sicking> | (probably needs some other name) |
| 18:14 | <sicking> | which returns a nde NodeList which is a subset of the first NodeList |
| 18:14 | <Lachy> | how can a NodeList match a selector? |
| 18:14 | <sicking> | containing just the nodes that matches the selector |
| 18:15 | <Lachy> | yeah, that's what NodeList.querySelectorAll() would do |
| 18:15 | <sicking> | match each node individually, return the ones that matches |
| 18:15 | <sicking> | really? |
| 18:15 | <Lachy> | yes. What else would it do? |
| 18:15 | <annevk2> | sicking, for CORS btw I had a thought of making redirects work for simple requests but not allowing the for stuff that involves the cache (i.e. complex requests) |
| 18:15 | <sicking> | i would have expected NodeList.querySelectorAll to call .querySelectorAll on each node in the nodelist and return a union of the resulting nodelists |
| 18:15 | <Lachy> | wow, that seems crazy |
| 18:16 | <sicking> | annevk2: yeah, i think we might want to go that way for v1 |
| 18:16 | <annevk2> | my main use case has always been simple requests |
| 18:16 | <sicking> | Lachy: that's what john resig suggested last i talked to him a few days ago |
| 18:16 | <annevk2> | because i'd like this to work nicely for e.g. eventsource; cross-origin images that do not have to taint <canvas>, etc. |
| 18:16 | <Lachy> | woah. That would be doing like what Array.forEach() does |
| 18:17 | <annevk2> | for those cases you need redirects to work just fine, especially for <img>, because cross-origin redirects already work fine :) |
| 18:17 | <sicking> | Lachy: in any event i would not expect querySelectorAll to work as a list "generator" in some cases and a filter in others, that seems very surprising |
| 18:18 | <Lachy> | it makes sense to do that, so that it's consistent with Element.querySelectorAll(). |
| 18:18 | <Lachy> | maybe it could be called filterSelector or something |
| 18:19 | <sicking> | right, with that name it makes much more sense |
| 18:19 | <sicking> | annevk2: not fully following you |
| 18:19 | <sicking> | annevk2: oh |
| 18:19 | <sicking> | annevk2: yeah, i agree, simple requests are the most important |
| 18:19 | <Lachy> | what's the use case for the other alternative, of invoking querySelector() on all nodes in the list and returning one collection? |
| 18:19 | <Lachy> | JohnResig, yt? |
| 18:20 | <sicking> | Lachy: don't know. But based on the name that's what i'd expect |
| 18:20 | <Lachy> | it's absolutely not what I'd expect |
| 18:21 | <sicking> | you'd expect it to be building lists when called on elements, but filtering them when called on NodeLists? |
| 18:21 | <TabAtkins> | Lachy: All of the direct traversal functions (children(), parent(), etc.) will operate on each individual element if called on a list of elements. |
| 18:21 | <sicking> | what about if the NodeList just contains one element? |
| 18:21 | <TabAtkins> | So, frex, $("p").parent() will give you a list of the parents of all <p>s. |
| 18:22 | <Lachy> | sicking, no difference |
| 18:22 | <TabAtkins> | There is not currently a direct way to do this with an arbitrary selector, though. |
| 18:22 | <Lachy> | TabAtkins, what traversal functions apply to NodeLists? |
| 18:22 | <sicking> | Lachy: so calling it on an element vs. calling it on a NodeList with that element would do two totally opposite things? |
| 18:23 | <TabAtkins> | Lachy: None of them. They only apply to jQuery objects. ^_^ |
| 18:23 | <TabAtkins> | Which can be both a single element or a list of elements. |
| 18:24 | <annevk2> | sicking, got to go now, will follow up on this tomorrow |
| 18:24 | <sicking> | annevk2: sounds good |
| 18:24 | Philip` | wonders if some mail system somewhere broke |
| 18:24 | <annevk2> | sicking, today I spent most of my time in my inbox, hopefully tomorrow I can actually get some work done :) |
| 18:24 | <Philip`> | I posted to public-html ~30 minutes ago and it's still not there :-( |
| 18:24 | <Lachy> | sicking, no. On Elements, it says, return all the matching elements contained within it, and on NodeLists, it says return all the matching elements contained within that |
| 18:25 | <TabAtkins> | Lachy: But the notion of "elements contained within it" is different for the two. |
| 18:25 | <Lachy> | so? |
| 18:26 | <Lachy> | but anyway, it doesn't matter. I can accept calling it something with a clearer name |
| 18:26 | <TabAtkins> | So it feels weird (if you're trying to justify the behavior where it filters the NodeList). |
| 18:26 | <TabAtkins> | kk |
| 18:27 | <sicking> | Lachy: agreed. The element object doesn't represent a list of nodes contained within it |
| 18:27 | <sicking> | (agree with TabAtkins that is) |
| 18:28 | <TabAtkins> | From my own experience in jquery, though, the most natural behavior for NodeList.querySelectorAll is to return a single collection that is the union of calling querySelectorAll on each Element in the NodeList. |
| 18:28 | <sicking> | well.. i *think* there might be a usecase for querySelectorAll on NodeList, which does the foreach thing. But I don't know what the use cases are so i'd ahve to refer to JohnResig |
| 18:28 | <sicking> | *defer to |
| 18:29 | <TabAtkins> | Actually... |
| 18:29 | TabAtkins | goes off to check the behavior of giving a context to $ that is multiple elements. |
| 18:29 | <TabAtkins> | jQuery *may* already have a behavior for this. |
| 18:32 | <TabAtkins> | !_! FF is suddenly interpreting my jquery file as something crazy in chinese. wtf? |
| 18:33 | <Dashiva> | Go go charset detection |
| 18:33 | <TabAtkins> | It's acting like it suddenly swapped over to UTF-16 parsing. |
| 18:33 | <TabAtkins> | Not certain about that, of course. |
| 18:35 | <Philip`> | Maybe it's displaying a gzipped version? |
| 18:36 | <TabAtkins> | Ah, no. For some reason my *text editor* was in utf-16LE mode, and so Windows was correctly sending the charset over to ff. |
| 18:36 | <TabAtkins> | And then ff was interpreting the jquery file in the same charset, since I didn't have one specified. |
| 18:37 | <TabAtkins> | k, fixed. |
| 18:37 | <TabAtkins> | Anyway! Lachy, jquery *does* have such a behavior already defined. |
| 18:39 | <Lachy> | ok |
| 18:41 | <TabAtkins> | $("i", $("div")) returns a jquery object containing all the <i>s contained in all the <div>s. |
| 18:41 | <Lachy> | how is that different from $("div i") |
| 18:42 | <TabAtkins> | Oh, duh, I am also dumb. The most direct analog is just find(). $("div").find("i") would do it. |
| 18:42 | <TabAtkins> | Lachy: The difference is that it's in two steps, producing a list and then running a selector over that list. |
| 18:42 | <Lachy> | but how is the result different? |
| 18:42 | <TabAtkins> | It's not. |
| 18:42 | <Lachy> | so what's the point? |
| 18:43 | <TabAtkins> | ?_? So you can run the first query, possibly alter the list, then run the second query. |
| 18:43 | <Lachy> | mine would be more efficient |
| 18:43 | <Lachy> | ok, so you were just using it to illustrate the concept, not a practical example. |
| 18:43 | <TabAtkins> | $("div").find("i") is the same as $("div i"). But $elems.find("i") may not have an equivalent selector. |
| 18:43 | <Philip`> | TabAtkins: Like $("div").filter(some arbitrary js code).find("i") ? |
| 18:43 | <TabAtkins> | Philip`, yeah. |
| 18:44 | <JonathanNeal> | I have a question about proper element usage. I've translated the folllowing image into the following HTML @ http://madison.thewikies.com/html5test/question.html (both on that page) |
| 18:44 | <JonathanNeal> | There are three elements in each row on that page, time, title, and location - I'm using time for time, h1 for title, and p for location, but would there be a better element to use than p? |
| 18:45 | <TabAtkins> | JonathanNeal, no, I don't think so. |
| 18:46 | <TabAtkins> | It doesn't seem to fit into any of the particular semantics that html5 cares about, so it's just generic content as far as the language is concerned. |
| 18:46 | <JonathanNeal> | Just making sure this wasn't a time to use the address tag, or if it didn't matter either way. |
| 18:46 | <gsnedders> | JonathanNeal: No, address is for contact details. |
| 18:47 | <hober> | JonathanNeal: hCalendar would be a very good fit |
| 18:47 | <JonathanNeal> | So my <time> element usage generally considered acceptable, or should it be a generic div or p? |
| 18:48 | <TabAtkins> | <time> is great. Why wouldn't it be? |
| 18:49 | <hober> | I'm not crazy about having <time> and <h1> as siblings, personally |
| 18:50 | <JonathanNeal> | hober, when using hCalendar markup in html5, do certain things change, does class="dtstart" title="2007-10-05" become dtstart="2007-10-05" |
| 18:50 | gsnedders | would use a table for that |
| 18:50 | <hober> | (but that's just personal preference) |
| 18:50 | <gsnedders> | (and probably use th for the title) |
| 18:50 | <TabAtkins> | hober: Luckily it doesn't mess with sectioning, since the <h1> is heading the parent <article>. |
| 18:50 | <hober> | JonathanNeal: <time class="dtstart" ...>...</time> |
| 18:53 | <JonathanNeal> | If I don't need to specify a start and end time, is just dtstart okay? |
| 18:55 | <hsivonen> | http://norman.walsh.name/2009/09/22/RDFaForDocBook |
| 18:56 | <hober> | JonathanNeal: http://microformats.org/wiki/hcalendar#Property_List says dtstart is required but dtend is optional. You might want to look into what it means to leave dtend off though. |
| 18:57 | <JonathanNeal> | I updated the html syntax @ http://madison.thewikies.com/html5test/question.html : temporary css withstanding. |
| 18:57 | <hober> | hsivonen: you could s/DocBook/HTML/ and most of that would hold up |
| 18:59 | <hober> | JonathanNeal: where you have title="" I think you mean datetime="" |
| 18:59 | <TabAtkins> | JonathanNeal: Any reason you've wrapped a span around the title, rather than just putting the class on <h1>? |
| 18:59 | <hober> | also, what's with the <a href="javascript:;">? |
| 18:59 | <hober> | why use span for summary? you could just put class="summary" on the h1 |
| 19:00 | <JonathanNeal> | Yea, you're totally right, that was pretty crappy of me.. |
| 19:01 | <JonathanNeal> | hober, the javascript:; is just to create totally empty links. |
| 19:01 | <hober> | <p class="location adr"><span class="locality">Orlando</span>, <abbr title="Florida" class="region">FL</abbr></p> |
| 19:02 | <hober> | why do you want totally empty links? |
| 19:02 | <JonathanNeal> | Well, before I implement it, I may just put an alert or something in there to test them, whatever. |
| 19:03 | <TabAtkins> | You can't just omit the href? |
| 19:03 | <TabAtkins> | Or, the standard way to handle that is href="#" |
| 19:05 | <JonathanNeal> | If it's a deal, I'll change it to # while I show you guys :D |
| 19:05 | <Philip`> | HTML5 allows <a> without href |
| 19:05 | <JonathanNeal> | I wonder if I'm using the <time> element (typically inline) incorrectly as a sibling there with the h1 as someone pointed out |
| 19:05 | <Philip`> | as a placeholder for elements that are sort of links without the link |
| 19:06 | <Philip`> | if I remember correctly |
| 19:06 | <TabAtkins> | Nah, it's just as conforming as <i> or <span> there, JonathanNeal |
| 19:06 | <JonathanNeal> | All right, I've updated the example. |
| 19:07 | <TabAtkins> | (content model of <article> is "flow content", which includes <time>) |
| 19:07 | <hober> | JonathanNeal: block and inline are CSS concepts, and no longer directly correspond to HTML's content models |
| 19:08 | <JonathanNeal> | Oh, groovy. |
| 19:11 | <TabAtkins> | :headdesk: The difference between if and elseif is important. |
| 19:12 | <Philip`> | What language has elseif? |
| 19:12 | Philip` | can only remember elif (Python), elsif (Perl) and else if (C/JS/Java) |
| 19:12 | <TabAtkins> | php |
| 19:12 | <Philip`> | Oh, okay |
| 19:12 | <TabAtkins> | "else if" is of course also allowed, and is equivalent. |
| 19:13 | Philip` | aims to know as little as possible about PHP |
| 19:13 | <Philip`> | That seems pointlessly redundant |
| 19:13 | <TabAtkins> | That's php for you. |
| 19:15 | <AryehGregor> | elif and elsif in Python/Perl actually serve logical purposes. PHP probably copied them in a cargo-cult fashion. |
| 19:15 | <AryehGregor> | Since PHP uses C-style ifs, so "else if" makes sense without special definitions. |
| 19:15 | <TabAtkins> | That's almost certainly what happened. |
| 19:15 | <TabAtkins> | We loves us some cargo-cultism. |
| 19:17 | TabAtkins | is happy that he finally has a Hindi translation for his company's app again. |
| 19:18 | <TabAtkins> | It mysteriously corrupted itself some time ago into jibberish, and nobody had backups going back far enough to fix them. |
| 19:21 | <AryehGregor> | Do you have many Hindi users? |
| 19:22 | <Philip`> | sicking: Your option 5 would cause unusual behaviour in text/html content like <svg xmlns:xlink="foo"><foreignObject><p property="xlink:bar"></foreignObject></svg> |
| 19:22 | <Philip`> | (because xmlns:xlink (and only xmlns:xlink) on foreign objects goes in the XMLNS namespace) |
| 19:22 | <TabAtkins> | Dunno the exact number, but we have some at least. It's just a "member language", though, so this only affects customer-facing stuff like receipts and reports, not the app interface itself. |
| 19:23 | Philip` | refrains from saying that on the list, because it's an irrelevant distraction |
| 19:23 | <TabAtkins> | We cover very nearly every language used by our customers. |
| 19:24 | <sicking> | Philip`: ah, interesting |
| 19:25 | <AryehGregor> | "Copy-and-paste from sites that didn't understand the spec, for example copying from w3schools.com" Zing. |
| 19:26 | <Philip`> | TabAtkins: That sounds like a challenge for someone to learn many obscure languages and then become a customer of you |
| 19:26 | <TabAtkins> | Thus the "very nearly" weasel. |
| 19:27 | <Philip`> | If I learn a hundred obscure languages, then you'll only support maybe half the languages used by your customers, which is not "very nearly every language" |
| 19:28 | <Philip`> | no matter how weaselly you try to be |
| 19:28 | <AryehGregor> | Hurrah, Chromium on Linux has progressed from "don't display Flash at all" to "display Flash but it instantly crashes every time". |
| 19:28 | <jgraham> | Philip`: Only if you "used" all 100 languages |
| 19:28 | <TabAtkins> | Only if you aggregate purely by language. I prefer to aggregate by language-instance, in which case you'd represent less than .1%. |
| 19:29 | <jgraham> | AryehGregor: That sems like the right pnalty for using flash |
| 19:29 | <jgraham> | *penalty |
| 19:29 | <AryehGregor> | jgraham, I wish I never had reason to. :( |
| 19:29 | <AryehGregor> | Why doesn't YouTube roll out HTML5 video already? :/ |
| 19:29 | <Philip`> | Because they hate standards |
| 19:30 | <AryehGregor> | What, Google hates HTML5 and they're paying the editor? |
| 19:30 | <Philip`> | Just see what they're doing to RDFa for evidence! |
| 19:30 | <Philip`> | AryehGregor: That gives them a great cover story |
| 19:30 | <AryehGregor> | Well, the fact that Google employs Hixie certainly supports the hypothesis that they hate RDFa specifically. :P |
| 19:30 | <TabAtkins> | Hahaha |
| 19:31 | <Philip`> | Pay one person to give the impression of supporting HTML5, and then you've got an excuse no matter what your zillion other employees do |
| 19:31 | <AryehGregor> | Well, they also paid people to implement <video> in Chrome. |
| 19:31 | <AryehGregor> | I think that's even released in the stable channel now. |
| 19:31 | <Philip`> | Oh, okay |
| 19:32 | <Philip`> | They must be trying to hide something *really* important if they're going to such lengths to give a false impression |
| 19:37 | <AryehGregor> | This would be much awesomer if some sample results were provided: http://wondermark.com/554/ |
| 19:52 | <TabAtkins> | AryehGregor: I've got lunch now. Gimme 10 minutes. |
| 19:56 | <TabAtkins> | Actually, gonna go actually grab lunch first. Then programming. |
| 20:07 | <annevk2> | well look at that, I wasn't the only one to look into CORS redirects today |
| 20:07 | annevk2 | is back for a bit |
| 20:24 | <annodomini> | So, is anyone working on speccing X-UA-Compatible (or the non prefixed version) now that we have two implementations of it? |
| 20:24 | <annodomini> | http://blog.chromium.org/2009/09/introducing-google-chrome-frame.html |
| 20:26 | <AryehGregor> | TabAtkins, http://dpaste.com/96903/ |
| 20:26 | <AryehGregor> | That totally wasn't worth the effort. |
| 20:27 | <TabAtkins> | However, your work enables me to use it more easily. ^_^ |
| 20:27 | <AryehGregor> | Wow, so Google makes an IE plugin that basically just replaces the entire guts of the browser with Chrome? Cool stuff. |
| 20:28 | <remysharp> | But if the user had a choice to actually install the plugin, surely they'd be savvy enough to install chrome (or any other browser) in the first instance? Doesn't it? |
| 20:29 | <AryehGregor> | No, because they won't notice a real difference between the plugin and the normal browser. |
| 20:29 | <AryehGregor> | They use the same icon and same interface and so on. |
| 20:29 | <Philip`> | remysharp: Then the user would have to actively choose which browser to use, based on whether they want a decent browser or they want compatibility with IE-only sites |
| 20:29 | <AryehGregor> | That too. |
| 20:29 | <Philip`> | whereas this way they get the rubbish browser for almost all sites, and Google can make its own sites render faster for users with the plugin |
| 20:29 | <AryehGregor> | TabAtkins, you get to find the bugs for yourself where I forgot a trailing comma and Python helpfully combined the strings. |
| 20:30 | <AryehGregor> | (I used to think PHP was stupid for requiring a . to concatenate string literals, now I'm not so sure) |
| 20:30 | <TabAtkins> | Using + for concat is dumb. >_< |
| 20:30 | <remysharp> | right, but the problem is that "older " browser are in high circulation because either the user or the sysadmins can't move the users on to new browsers - so equally they won't be able to install a plugin that tweaks their browser |
| 20:31 | <miketaylr> | right, but the new plugin won't break their vbscript-laden internal apps. |
| 20:31 | <AryehGregor> | remysharp, 1) Is installing a plugin really as hard as installing a new browser? Does IE require admin privileges to install a plug-in, for instance? 2) A lot of places haven't switched because they need IE for internal sites. This rendering engine is opt-in, so not an issue. |
| 20:32 | <Philip`> | Using chrome=1 to trigger behaviour in IE seems like a violation of how I expect x-ua-compatible to work - it'd make more sense to me if it said ie=chrome |
| 20:32 | <remysharp> | AryehGregor: The video of Hilton being asked why they couldn't use Firefox was responding with the cost of support |
| 20:32 | <remysharp> | and the related support when they do image installs of machines |
| 20:32 | <remysharp> | (or something to that nature) |
| 20:33 | <AryehGregor> | Not an issue if the users can install plugins when the site asks them without sysadmin approval, now, is it? :) |
| 20:33 | <remysharp> | sure |
| 20:33 | <remysharp> | but they're not the problem |
| 20:33 | <TabAtkins> | Philip`, I agree with you. This isn't recognizing a version of Chrome, it's recognizing a version of IE. |
| 20:33 | <remysharp> | Also - I'm not sure how good this looks: http://www.grabup.com/uploads/1c33a86d16fc998ee6ae5b531f32e211.png?direct |
| 20:35 | <AryehGregor> | remysharp, they are if you get to the point where you're willing to say "If you use IE, you have to install this plugin to continue." |
| 20:35 | <paul_irish> | remysharp: i should point out that was from ie4osx which, who knows what sort of userAgent it reports.. |
| 20:35 | <paul_irish> | but i think the install flow could be a lot better. |
| 20:35 | <remysharp> | paul_irish: hi! :-) |
| 20:36 | <remysharp> | paul_irish: right, and since when was reading the userAgent the right way to do detection? |
| 20:36 | <remysharp> | well - since a while back, but not today! |
| 20:36 | <AryehGregor> | "True, but IE handles legacy compatibility by versioning." Interesting, I didn't know that would be the official policy forever going forward. That's what that sounds like. |
| 20:36 | <remysharp> | and equally, what about the whole X-UA... IE=edge - can we comma separate them, to read: "IE=edge,chrome=1"? |
| 20:36 | <AryehGregor> | (from travil⊙mc on www-style, FWIW) |
| 20:36 | <remysharp> | or is one going to overwrite the other? |
| 20:37 | <remysharp> | sorry, I've hijacked the #whatwg discussion for something that's pretty off topic. I shouldn't rant off too much :-) |
| 20:42 | <Lachy> | sicking, the NodeList.querySelector() proposal, where it returns the collective result from all elements, seems a little more complicated to define than I first thought. |
| 20:43 | <Lachy> | it would have to return the union of all results, but then it gets complicated if the same node is matched twice |
| 20:44 | <Lachy> | so it would have to somehow say that each node is included in the list only once |
| 20:44 | <Lachy> | but it makes it hard to guarantee the order in which nodes are returned |
| 20:45 | <miketaylr> | Lachy: but isn't union defined as the set of all unique elements in a collection? |
| 20:45 | <Philip`> | remysharp: It seems much more on-topic than many other things here :-) |
| 20:45 | <miketaylr> | (at least in linguistics, i believe it is) |
| 20:45 | <Lachy> | the problem is more the order of the elements indexed in the NodeList |
| 20:45 | <miketaylr> | ah |
| 20:45 | <AryehGregor> | In set theory it is. Not in, for instance, SQL. |
| 20:46 | <AryehGregor> | (UNION ALL vs. UNION DISTINCT) |
| 20:46 | <Philip`> | http://philip.html5.org/data/ua-compatible-contents.txt is fun to see how many people blindly copy-and-paste |
| 20:46 | <Lachy> | right. I think we'd want the equivalent of UNION DISTINCT |
| 20:46 | <remysharp> | Philip`: I love the last one |
| 20:47 | <miketaylr> | AryehGregor: yeah, thanks for the distinction. |
| 20:47 | <Philip`> | http://philip.html5.org/data/ua-compatible-headers.txt too |
| 20:47 | <remysharp> | "IE=7" <- this /really/ worries me long term. |
| 20:48 | <AryehGregor> | Why? |
| 20:49 | <Lachy> | AryehGregor, why what? |
| 20:49 | <hsivonen> | the chrome frame trigger is amusing |
| 20:49 | <AryehGregor> | [090922 15:55:40] <remysharp> "IE=7" <- this /really/ worries me long term. <-- Why? |
| 20:49 | <remysharp> | It's there because "MS want to support those sites who can't change to support IE8" - so instead you stick "IE=7" and in another 5 years, we're stuck with IE7 rendering pages |
| 20:50 | <remysharp> | and it's ie6 all over again |
| 20:50 | <AryehGregor> | It's Microsoft's problem, surely, not anyone else's. |
| 20:50 | <AryehGregor> | The point is to encourage users to upgrade. |
| 20:50 | <AryehGregor> | Since they can keep the old way of rendering. |
| 20:51 | <AryehGregor> | (for their sites) |
| 20:51 | <roc> | hsivonen needs to update his "IE rendering modes chart" now! |
| 20:51 | <remysharp> | Sure, but they also happen to be the dominant browser still - and could remain that way |
| 20:51 | gsnedders | remembers this debate before |
| 20:51 | <Philip`> | AryehGregor: It discourages authors from updating their sites to work in standards-compliant browsers, and therefore it harms users of standards-compliant browsers |
| 20:51 | <remysharp> | so if they say we're focusing on support the shit around the web instead of this fancy new stuff. |
| 20:51 | <remysharp> | .... |
| 20:51 | <Lachy> | haha, which site is using IE=4, and the one beginning "Dear M$..." |
| 20:51 | <hsivonen> | roc: yeah. more community service coming up for me |
| 20:52 | <roc> | it's just going to get more and more exciting over time |
| 20:52 | <AryehGregor> | Philip`, no, it encourages users to upgrade to more standards-compliant browsers (higher versions of IE), and therefore allows authors to update their sites to work in more standards-compliant browsers without special-casing IE everywhere. |
| 20:53 | <remysharp> | but that's not a realistic approach. Users can't upgrade, often those ones stuck, it's not their choice. And then our clients ask us to, rightly, support IE6 because it's a browser with significant dominance. |
| 20:53 | <Lachy> | AryehGregor, it's a questionable technique designed to allow Microsoft to play catch up without causing too much pain for developers now, at the expense of causing themselves pain in the long run |
| 20:53 | <remysharp> | anyway, this is an old argument that goes round in circles. |
| 20:54 | <AryehGregor> | Yes, so it's arguably a bad idea on Microsoft's part, but I think for authors it's generally a positive thing. |
| 20:54 | <AryehGregor> | I don't know why they'd need it beyond IE8 or so. |
| 20:54 | <AryehGregor> | The problem was surely that they painted themselves into a corner with totally broken CSS support in IE6 and IE7. |
| 20:54 | <AryehGregor> | (especially IE6) |
| 20:54 | <AryehGregor> | Well, CSS and a fairly long list of other things. |
| 20:55 | <AryehGregor> | But I think CSS was the biggest problem. |
| 20:55 | <gsnedders> | AryehGregor: I'd say that wouldn't have been such a problem if IE6 didn't have such a long release cycle |
| 20:55 | <AryehGregor> | Yes, that's true too. |
| 20:55 | <AryehGregor> | Although then authors would have to do three times as many hacks to get *all* the versions of IE to work, of course. |
| 20:56 | <gsnedders> | Someone from MS (Chris, maybe) said they would've probably fixed more bugs and delayed IE6 if they knew it was going to have such a long release cycle |
| 20:56 | <Lachy> | there's a small chance Microsoft could, if they tried hard enough, phase out support for it over the long term, as old sites relying on it now eventually get rebuilt to not rely on it. |
| 21:00 | <Philip`> | Lachy: http://www.ecan.govt.nz/Plans+and+Reports/Air/RoadsideMonitoring.htm had IE=4 |
| 21:01 | <Philip`> | Lachy: http://forum.pcekspert.com/member.php?u=14720 had the letter |
| 21:01 | <jgraham> | Lachy: NodeList.querySelectorAll should return the document-ordered union of the results of querySelectorAll applied to each Node in NodeList |
| 21:02 | <jgraham> | NodeList.matchAll or whatever should return the elements of the NodeList that match in the original order of the nodelist |
| 21:03 | jgraham | is waiting for the day that hsivonen has to convert his flowchart to a 3D flythrough |
| 21:11 | <jgraham> | OK html5lib testcase: <body><frame></frame></frame><frameset><frame><frameset><frame></frameset><noframes></frameset><noframes> |
| 21:12 | <jgraham> | There is an explicit <body> tag so in after-head mode we set the frameset-ok flag to not ok |
| 21:14 | <jgraham> | Then we switch to in-body and ignore all the <frame></frame> junk |
| 21:15 | <jgraham> | Then when we hit the <frameset> tag frameset-ok is still not OK |
| 21:16 | <jgraham> | So we ignore the token |
| 21:16 | <jgraham> | The first token that is inserted is that corressponding to the noframes element |
| 21:17 | <jgraham> | and the final tree should be |
| 21:17 | <jgraham> | <html> |
| 21:17 | <jgraham> | <head> |
| 21:17 | <jgraham> | <body> |
| 21:17 | <jgraham> | <noframes> |
| 21:17 | <jgraham> | "</frameset><noframes>" |
| 21:17 | <jgraham> | What did I miss? |
| 21:18 | <jgraham> | I think the testcase output is right for the situation where there is no explicit <body> tag because then you rest the frameset-ok flag to OK in after-head mode |
| 21:18 | <jgraham> | after inserting the body element |
| 21:25 | <TabAtkins> | Hmm, anybody know if it's documented just how IE is *supposed* to react to a conditional comment started in the <head> which contains a </head>? It looks like it implicitly closes the comment. |
| 21:26 | <TabAtkins> | Never mind, I'm probably crazy. |
| 21:30 | <TabAtkins> | So, <dt>/<dd> within <figure>/<details> is back to being on the table, since there's a small hack (smaller than document.createElement()) that fixes IE<8 parsing. |
| 21:31 | <TabAtkins> | Unfortunately I can't just pass this off to a js file. I'm actually going to have to carry around a copypasta talisman to put into all of my pages. |
| 21:31 | <gsnedders> | fail. |
| 21:59 | <mookid> | Hixie: did you just make that up? :P |
| 22:07 | <Hixie> | AryehGregor: http://youtube.com/html5 |
| 22:12 | <cardona507> | chrome frame - oh thank god |
| 22:23 | Philip` | tests librdfa |
| 22:23 | <Philip`> | Hmm, it doesn't even seem to support <p XMLNS:EX="..." property="ex:..."> |
| 22:23 | <Philip`> | That's not very conforming |
| 22:24 | <Philip`> | It also seems to abort and return an empty document (instead of an RDF response) with certain inputs like xmlns:0 |
| 22:24 | <Philip`> | It does something really weird with xmlns:_ |
| 22:25 | <Philip`> | <p xmlns:ex="" property="ex:http://example.com/test">Test</p>; turns into <> <file:////http> "Test" . which is crazy |
| 22:29 | <Philip`> | s/RDF/RDF\/XML/ |
| 22:31 | <sicking> | annevk2: ping |
| 22:33 | <Hixie> | Philip`: i believe you're missing the point... all that's necessary is for someone to _claim_ that they support rdfa, that's enough to indicate rdfa is a success |
| 22:36 | <sicking> | Hixie: so what's the reason for the itemfor attribute? |
| 22:36 | <sicking> | Hixie: that's pretty new, right? |
| 22:37 | <Hixie> | sicking: used to be called subject="" |
| 22:37 | <sicking> | Hixie: another thing, it would be great with more examples in the microdata section. Right now there's only extremely primitive examples, and huge examples |
| 22:37 | <Hixie> | sicking: i'll be adding a bunch once the study's results are in |
| 22:37 | <Hixie> | didn't want to change the spec until i got hte results back |
| 22:37 | <sicking> | Hixie: i tried to see how to define an item with a sub-item the other day, the only examples of that are huge |
| 22:38 | <Hixie> | http://damowmow.com/playground/microdata/001/ has examples and stuff that might help |
| 22:38 | <sicking> | Hixie: cool |
| 22:38 | <Hixie> | review-annotated.html shows itemfor="" iirc |
| 22:39 | <sicking> | Hixie: so what's the use case for itemfor/subject? |
| 22:39 | <Hixie> | review-annotated.html shows the use case |
| 22:40 | <sicking> | so one fairly big problem with it is that the reference goes in an unexpected direction |
| 22:40 | <sicking> | Hixie: which means that in order to extract microdata from anywhere, you need to scan the whole document |
| 22:42 | <Hixie> | yes |
| 22:42 | <sicking> | why not make the reference go the other way? |
| 22:42 | <sicking> | using a <meta> or something |
| 22:43 | <sicking> | Hixie: on an unrelated subject. Why does HTMLMediaElement expose the errorcode as an object? Rather than as a integer |
| 22:44 | Philip` | notes that <meta> doesn't actually work in practice today because some browsers move it into <head> |
| 22:44 | <Philip`> | (unless that was <link>? or both?) |
| 22:44 | <jgraham> | (I think <meta> doesn't work indeed) |
| 22:44 | <sicking> | Hixie: forcing you to go through media.error.code, rather than just media.error |
| 22:44 | <jgraham> | (I would bring it up as a problem but I feel like I complain too much already) |
| 22:44 | <sicking> | Hixie: trying to figure out if we should copy this pattern for FileRequest |
| 22:45 | <Hixie> | sicking: yeah we could go the other way... I'll ponder it once the study's results are in next week |
| 22:45 | <sicking> | Hixie: cool |
| 22:45 | <Hixie> | media.error is intended for future extension, so you can find out exactly what frame the error happened at, etc |
| 22:45 | <Hixie> | iirc |
| 22:47 | <TabAtkins> | sicking: The nice thing about itemfor's directionality is precisely that the Microdata parent doesn't need to know about its children explicitly, which matches the model when they are DOM children as well. |
| 22:48 | <TabAtkins> | It would suck if you had some vocab that could contain an unbounded number of some property, and you could just automagically associate all of the DOM children of the vocab root, but had to explicitly list the ones that weren't children. |
| 22:48 | <sicking> | Hixie: ok |
| 22:49 | <Hixie> | TabAtkins: we could do it in a way that linked to another node that acted as parent |
| 22:49 | <Hixie> | i did actually design a feature to do this, <ref> |
| 22:49 | <Hixie> | but i didn't want to add a new element to do it |
| 22:50 | <TabAtkins> | Interesting. Would the real parent refer to the ref, or the ref refer to the real parent? |
| 22:53 | <sicking> | Hixie: really? you're complaining that other peoples specs should be split into separate specs? ;-) |
| 22:54 | <Hixie> | or chapters |
| 22:54 | <Hixie> | and hey, i've split html5 into an ungodly number of specs by now |
| 22:54 | <Hixie> | so it's not like i don't have a leg to stand on :-P |
| 22:54 | <gsnedders> | You haven't split window out yet ;P |
| 22:55 | <Hixie> | that'll never happen |
| 22:55 | <gsnedders> | (Yes, yes, yes, I know you want xdoc xref) |
| 22:55 | <sicking> | but Window is the one that need it the most |
| 22:56 | <Hixie> | splitting Window would take me months |
| 22:57 | <sicking> | Hixie: get crackin' ;) |
| 22:57 | <Hixie> | not |
| 22:57 | <Hixie> | gonna |
| 22:57 | <Hixie> | happen |
| 22:58 | <sicking> | boooo |
| 23:01 | <sicking> | Hixie: i'm implementing your dope XBL2, i think you owe me |
| 23:01 | <gsnedders> | sicking: Stop implementing it! |
| 23:01 | <sicking> | gsnedders: huh? |
| 23:01 | <gsnedders> | sicking: Go on strike! |
| 23:01 | <Hixie> | sicking: i owe you big, if you really do implement it! |
| 23:01 | <sicking> | gsnedders: hah |
| 23:01 | <sicking> | Hixie: sounds like we have a deal |
| 23:02 | <sicking> | though i suppose i could choose something more fun |
| 23:02 | <sicking> | like multiplex support for websocket |
| 23:02 | <sicking> | or some CSS goodness |
| 23:02 | <gsnedders> | Window! Window! |
| 23:06 | <mpilgrim> | "RDFa: for when interoperability really, really, really doesn't matter." (c.f. http://lists.w3.org/Archives/Public/public-html/2009Sep/0895.html ) |
| 23:07 | gsnedders | wonders what he's been missing on public-html this past month |
| 23:11 | <Dashiva> | mpilgrim: That's incorrect. Interoperability matters. It will just happen magically by itself. |
| 23:11 | <TabAtkins> | Ooh, sicking, I'll be happy if you implement XBL2 too! |
| 23:12 | <Dashiva> | Although it seems absurd to define a high-level concept like RDFa using source level concepts |
| 23:13 | <Hixie> | sicking: we should do lunch at some point to talk about multiplex in websocket. i'm not convinced either way on that, and everyone i speak to for advice is giving me different answers, ranging from "it's critical" to "it would be actively harmful" |
| 23:21 | <mpilgrim> | dashiva: I like how Shane says "I am *convinced* it would render the same prefix mappings" |
| 23:21 | <mpilgrim> | despite a complete lack of evidence that that is true |
| 23:21 | <mpilgrim> | and in the face of compelling evidence that it is false |
| 23:21 | <mpilgrim> | but he *believes*, so maybe that's enough |
| 23:21 | <mpilgrim> | actually, that would expain a lot |
| 23:22 | <mpilgrim> | "RDFa: the faith-based alternative to interoperability" |
| 23:22 | <TabAtkins> | Hehe. |
| 23:23 | <Dashiva> | It brings new meaning to "We believe in interoperability" |
| 23:23 | <TabAtkins> | Gah, I keep trying to write </endif> |
| 23:23 | <TabAtkins> | That's both wrong *and* redundant. |
| 23:24 | <sicking> | Hixie: i'm in |
| 23:24 | <sicking> | Hixie: after the end of this quarter |
| 23:25 | <sicking> | mpilgrim: IMHO the whole discussion shows that XML namespaces is just too complicated |
| 23:25 | <sicking> | mpilgrim: things were so much easier when a nodes identity was in its name only |
| 23:25 | <Dashiva> | But they don't use namespaces, they just the syntax of namespaces without any of the meaning |
| 23:25 | <sicking> | mpilgrim: of course, RDFa just piles on the namespace mess |
| 23:26 | <Hixie> | sicking: how's friday next week (10/2)? |
| 23:28 | <sicking> | Hixie: could we do thursday? I hope to work from home that friday |
| 23:28 | <Hixie> | sure, noon on thursday? meet in b43? or we can eat on castro if you like |
| 23:28 | <hober> | mpilgrim: Shane believes all sorts of weird things. http://edward.oconnor.cx/2009/07/web-worldview |
| 23:29 | <Hixie> | sicking: la fiesta is good too if you like |
| 23:31 | <mpilgrim> | hober: the w3c's primary responsibility hasn't been "moving the web forward" in a *long* time |
| 23:31 | <mpilgrim> | if ever |
| 23:31 | <mpilgrim> | a gracious interpretation of their mission would be "moving the intranet forward" |
| 23:31 | <mpilgrim> | very gracious |
| 23:32 | <Hixie> | it's primary _responsibility_ has been "moving the web forward"... |
| 23:32 | <sicking> | Hixie: either works. Haven't been to either place in a while |
| 23:32 | <Philip`> | The web is hard to move, so it's much easier to just redefine the web to be something that's much easier to move because it doesn't have a billion users sitting on top of it already |
| 23:32 | <sicking> | Hixie: might be easier for me to get up there, what with having a car and all |
| 23:33 | <Hixie> | sicking: la fiesta is walking distance from my house, so they're both fine for me |
| 23:33 | <mpilgrim> | viewing RDFa as a faith-based lifestyle choice resolves all sorts of questions, actually |
| 23:33 | <sicking> | Hixie: oh, cool, lets do that then |
| 23:33 | <Hixie> | right-o |
| 23:33 | Hixie | calendars himself |
| 23:33 | <mpilgrim> | the whole "that's a pathological test case, so my answer would be 'just don't do that'" thing |
| 23:33 | gsnedders | ought to go to northern CA sometime |
| 23:33 | <Hixie> | thursday 10/1 noon at la fiesta, meet with sicking about multiplexing |
| 23:33 | <mpilgrim> | you're not testing his spec |
| 23:33 | <mpilgrim> | you're testing his faith |
| 23:33 | <mpilgrim> | and his faith can not be shaken |
| 23:34 | <mpilgrim> | a true believer would not write such a test case |
| 23:35 | <Philip`> | It seems RDFa proponents are focusing mostly on the important but obvious and thus uninteresting aspects, like whether <!doctype html><p xmlns:ex="..." property="ex:..."> in text/html should work (which it obviously should) |
| 23:36 | <Philip`> | while some other people are focusing on the less important but more complex aspects, like precisely defining handling of unobvious edge cases |
| 23:38 | <Philip`> | so it's not helpful when proponents keep pointing out that the simple obvious cases work, because obviously they do, and we're interested in the weird crazy things because that's where the spec is broken |
| 23:39 | <Philip`> | (and that's where there's little interoperability in current implementations) |
| 23:40 | <mpilgrim> | i have to believe there's a bit of "it's hard to get a man to understand something when his paycheck depends on not understanding it" going on here |
| 23:40 | <mpilgrim> | (with apologies to upton sinclair, who was talking about something far more important) |
| 23:41 | <mpilgrim> | Philip`: yes, but how do you explain their reaction to evidence that there is little interoperability in the implementations they cite? |
| 23:41 | <mpilgrim> | their reaction to google's not-really-RDFa implementation was "that's not a validator" |
| 23:42 | <Dashiva> | mpilgrim: Also, it only happens in edge cases, they don't matter in the real world |
| 23:42 | <TabAtkins> | I'm just skimming the convos, but that didn't make any sense to me. Of course it's not a validator. No one's claiming it is. They're claiming it's not a *consumer*. |
| 23:42 | <Philip`> | In the past there was explicit agreement that RDFa ought to precisely specify the output triples for any input (regardless of validity), so that doesn't seem contentious, so I don't know why there seems to be so much pushback against actually specifying it clearly |
| 23:42 | <TabAtkins> | At least, not a consumer that anyone can rely on to consume the RDFa that they put into their pages, following the spec as closely as possible. |
| 23:43 | <mpilgrim> | dashiva: right, they haven't yet internalized that the entire world is just a massive collection of edge cases |
| 23:43 | <Philip`> | (Google's RDFa thing has even more serious problems, like thinking HTML with <p property=...>...<p property=...> is two nested elements) |
| 23:43 | <Dashiva> | Philip`: Well, RDFa works on source level text, what is there to expect? |
| 23:43 | <mpilgrim> | like hixie's and hsivonen's explanation to that i18n dude that, for the purposes of the character encoding detection algorithm, the entire web was a legacy environment |
| 23:43 | <hober> | Dashiva: and, of course, the real world actually looks like a http://www.bakersedge.com/ pan |
| 23:44 | <Philip`> | Dashiva: Only the namespace stuff works on source level text, the HTML+RDFa draft explicitly says that the processing model operates on a tree model |
| 23:44 | <mpilgrim> | (on second thought, "that i18n dude" might have been a woman. if so, i apologize) |
| 23:44 | <TabAtkins> | ...why did that require a flash app with a 5-second loading time. |
| 23:44 | <Philip`> | Dashiva: (Don't ask me how those two views are meant to fit together) |
| 23:45 | <Dashiva> | Philip`: How are they meant to fit together? |
| 23:45 | <Philip`> | Dashiva: Curses! |
| 23:45 | <mpilgrim> | philip`: well, shelleyp did say (many moons ago) that the DOM was not an environment that was terribly important to her |
| 23:45 | <Dashiva> | It's an important question, though |
| 23:45 | <Philip`> | Dashiva: Now I'll have to intentionally refuse to answer you |
| 23:45 | <Dashiva> | Wanting both source text and object model at the same time is kinda schizophrenic |
| 23:45 | <mpilgrim> | if you ignore all those crazy DOM consumers, i bet RDFa works just fine |
| 23:46 | <mpilgrim> | and the XOM consumers |
| 23:46 | <mpilgrim> | and the consumers that use off-the-shelf parsing tools |
| 23:46 | <mpilgrim> | and Google |
| 23:46 | <hober> | shane and hsivonen's back-and-forth re: defined-in-terms-of-text v. defined-in-terms-of-an-object-model reminded me of Hixie's lunch with the TAG: http://ln.hixie.ch/?start=1180683614&count=1 |
| 23:47 | <Philip`> | The HTML+RDFa draft seems to still talk about the concrete syntax of namespace attributes, and so it seems to (unintentionally?) say that XMLNS:EX="..." should work in XHTML just the same as in HTML |
| 23:48 | <mpilgrim> | lol @ "The HTML working group is supposed to publish something (I suggest the spec)" |
| 23:48 | <Philip`> | which seems to be the kind of confusion that results when you talk about things in terms of syntax |
| 23:49 | <Philip`> | because you're mixing conceptual levels, trying to talk about the syntax that results in a certain parsed output (in this case lowercased attribute names) |
| 23:49 | <Philip`> | or, uh, something like that |
| 23:49 | <Philip`> | Please feel free to imagine my points are more coherent |
| 23:50 | <Dashiva> | Philip`: They're no less coherent than the spec ;P |
| 23:51 | <mpilgrim> | dashiva: you just don't *believe* hard enough |
| 23:51 | <Dashiva> | I believe I can parse, I believe I can touch the graph |
| 23:55 | Philip` | notes that RDF itself seems to be clearly and precisely specified, from what he's seen of it |
| 23:56 | <Philip`> | like it defines all the conceptual models it uses, and uses them correctly without accidentally mixing levels |
| 23:57 | <Philip`> | but RDFa seems much more confusing and seems to leave more things undefined |
