| 04:43 | <Dashiva> | Hum |
| 04:49 | <Dashiva> | "IO Error: Resource size exceeds limit" for http://validator.nu/?doc=http%3A%2F%2Fdev.w3.org%2Fhtml5%2Fspec%2FOverview.html |
| 04:49 | <Dashiva> | I was trying to check if the w3c version of the spec is real html4, or just html5 with a html4 doctype |
| 05:11 | <MikeSmith> | Dashiva: please try on http://qa-dev.w3.org:8888/ |
| 05:12 | <MikeSmith> | I upped the limit there |
| 05:12 | <MikeSmith> | the upstream limit at validator.nu is 4096KB |
| 05:12 | <MikeSmith> | and the spec is around 4300KB or so now |
| 07:11 | <hsivonen> | I wonder if the spec is going to grow like gmail storage space |
| 07:12 | <Hixie> | the sum of specs that define the web will, certainly |
| 07:13 | <Hixie> | whether we have that in one document or a great many or something in between is an editorial issue |
| 07:13 | <hsivonen> | well, looks like validator.nu needs to have its limit grown once in a while to accommodate the spec |
| 07:14 | <hsivonen> | it'll be interesting to see if at some point the limit grows larger than what would be appropriate to protect the VM from DoS |
| 07:18 | <MikeSmith> | hsivonen: welcome back |
| 07:18 | <hsivonen> | MikeSmith: thanks |
| 07:19 | <hsivonen> | MikeSmith: I'll look at your patches in due course. |
| 07:19 | <MikeSmith> | no hurry |
| 07:19 | <MikeSmith> | I got a couple more on the way |
| 07:20 | <MikeSmith> | I don't mean to overload you, just took advantage of the holiday break to try to get a few things written up |
| 07:23 | <MikeSmith> | hsivonen: btw, do you know of any reason why <style><!--></style> should be conforming? |
| 07:23 | <MikeSmith> | it's not conforming in the current spec |
| 07:23 | <MikeSmith> | in the ABNF for the contents of the style element |
| 07:24 | <Hixie> | hsivonen: the spec shouldn't have grown... it was working fine before the holidays for me, and i validate the complete version of the spec before preprocessing (i.e. about 13 specs at once) |
| 07:24 | <Hixie> | maybe the preprocessor overhead is more than i realised |
| 07:25 | <MikeSmith> | it was hitting the v.nu size limit well before the holidays |
| 07:25 | <hsivonen> | MikeSmith: how does that parse in legacy browsers? |
| 07:25 | <MikeSmith> | Hixie: a month or more ago |
| 07:25 | <MikeSmith> | hsivonen: not sure |
| 07:25 | <Hixie> | MikeSmith: the post-processed version? |
| 07:25 | <MikeSmith> | hsivonen: maybe Simon knows |
| 07:25 | <Hixie> | or the version i validate with all the specs? |
| 07:26 | <Hixie> | and w3c or whatwg? |
| 07:26 | <hsivonen> | I reran the deployment script. let's see if the new limit of 5 MB takes effect or if I need to restart the validator manually |
| 07:26 | <MikeSmith> | Hixie: the w3c one for sure |
| 07:26 | <MikeSmith> | but I thought the whatwg version also |
| 07:26 | <hsivonen> | MikeSmith: in any case, it seems to me that it's not important to make <style><!--></style> conforming |
| 07:26 | <Hixie> | MikeSmith: post-processed? |
| 07:26 | <MikeSmith> | hsivonen: OK |
| 07:27 | <MikeSmith> | Hixie: yesh |
| 07:27 | <Hixie> | i'm very surprised that the processing overhead is so high that html5 alone is bigger than the source of all the specs together |
| 07:28 | <MikeSmith> | hsivonen: I was asking mainly because it was conforming before -- the spec said something like, "An escaping text span start can share its "--" characters with its escaping text span end". |
| 07:29 | <MikeSmith> | so was wondering if somebody has maybe requested that it be conforming for some reason |
| 07:29 | <hsivonen> | MikeSmith: I haven't made any change in that area knowingly other than trying to implement the new tokenizer states as specced |
| 07:30 | <MikeSmith> | hsivonen: I meant just that it was conforming in the spec, before Hixie switched to the specific ABNF definition for style content |
| 07:31 | <MikeSmith> | I didn't mean to say that parser behavior had changed |
| 07:32 | <hsivonen> | MikeSmith: oh. I haven't looked at what the spec says about the conformance of style and script content now |
| 07:32 | <MikeSmith> | OK, anyway, I was wondering about it because I wrote up a style-content checker (after bug from Simon) |
| 07:33 | <MikeSmith> | which is one of the other patches I still need to send you for review |
| 07:33 | <MikeSmith> | and if that case were conforming, it would mean adding another state to the state machine that does the check |
| 07:34 | <MikeSmith> | but anyway, for now, I just implemented it to spec |
| 07:36 | <MikeSmith> | if there were ever somebody who wanted "<!-->" to be conforming, I guess they'll need to re-review the spec and send a comment to Hixie |
| 07:38 | <MikeSmith> | hsivonen: so the other patch I have ready is for this: |
| 07:38 | <MikeSmith> | http://qa-dev.w3.org:8888/?doc=http%3A%2F%2Fdev.w3.org%2Fhtml5%2Ftests%2Fvalidation%2Ffull%2Finvalid%2Fmissing-attributes%2Flink-missing-href.html |
| 07:39 | <hsivonen> | MikeSmith: what's the mechanism for making that happen? |
| 07:40 | <MikeSmith> | hsivonen: added all required-attributes to Assertions.java and have the build make copies of the meta.rnc, embed.rnc, media.rnc, and microdata.rnc files with the required attributes made optional in the schema |
| 07:41 | <MikeSmith> | the copies are, e.g, meta-vnu.rnc |
| 07:41 | <MikeSmith> | and are generated, so not in version control |
| 07:41 | <hsivonen> | ok |
| 07:41 | <MikeSmith> | used only internally by vnu |
| 07:41 | <MikeSmith> | does that sound sane? |
| 07:43 | <hsivonen> | MikeSmith: yes |
| 07:43 | <hsivonen> | (I really wish Jing could do this) |
| 07:43 | <MikeSmith> | hsivonen: OK |
| 07:43 | <MikeSmith> | yeah, I wish jing would do it too |
| 07:44 | <MikeSmith> | but one case I can imagine it being hard for Jing itself to report usefully on is the data and type attributes on the object element |
| 07:46 | <MikeSmith> | hsivonen: do you know if MSV reports usefully for required-but-missing attributes cases? |
| 07:46 | <hsivonen> | MikeSmith: I don't |
| 07:46 | <MikeSmith> | I tried to check with relaxed earlier, but the site seems to be down |
| 07:53 | <Hixie> | ok, vacation over |
| 07:54 | <Hixie> | so i'm supposed to get all these bugs done by sunday huh |
| 07:57 | <hsivonen> | Hixie: at least most of them are clear for straightforward fixing or wontfixing |
| 07:59 | <hsivonen> | what's the deal with the assignee change here: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238 ? |
| 08:01 | <othermaciej> | Hixie: would be nice to get 'em done, yeah - how many are open right now? |
| 08:01 | <othermaciej> | hsivonen: looks like an accident to me |
| 08:01 | <Hixie> | 212, shouldn't be a problem. though a number of them are things i'd really rather not resolve without knowing how the microdata issue gets resolved. |
| 08:03 | <othermaciej> | it's fine to pick out that subset and hold off, as long as you say so in the bugs (though I think we can have it resolved sometime in the coming week) |
| 08:04 | <othermaciej> | btw looking at the source of <http://dev.w3.org/html5/status/issue-status.html>; it seems we have resolved 6 HTML WG tracker issues since I started the status list |
| 08:04 | <Hixie> | http://damowmow.com/playground/htmlwg/chart.html looks good, indeed |
| 08:06 | <othermaciej> | probably at least some of the upcoming batch of bugs will turn into issues |
| 09:17 | <Hixie> | othermaciej: remind me - if i've included the boilerplate once, should i do it again if i'm closing the bug for the same reason? |
| 09:17 | <Hixie> | e.g. http://www.w3.org/Bugs/Public/show_bug.cgi?id=8096 |
| 09:17 | <othermaciej> | Hixie: if someone reopened it? |
| 09:17 | <Hixie> | marked it NEEDSINFO, asked for data, someone reopened it with information i still don't understand |
| 09:17 | <Hixie> | when i ask for further clarification and mark it NEEDSINFO again, do i include the "rejected" boilerplate again? |
| 09:18 | <othermaciej> | I think an explanation of why the new info is not helpful is sufficient, but it would be fine to also add the boilerplate |
| 09:18 | <workmad3> | ooh, I remember that one from mailing list discussions :) |
| 09:19 | <workmad3> | I quite liked the idea, up until the point someone made note of the fact it would be ****ing awful for backwards compatibility |
| 09:19 | <Hixie> | k |
| 09:19 | <AryehGregor> | Hixie, there was a long discussion here on that one. It's completely crazy. He wants to have different resources served under the same URL, distinguished by the client's Accept header, like mysite.com/ returning a feed if you send Accept: application/rss+xml and a web page if you send Accept: text/html, or something similarly lunatic. |
| 09:19 | AryehGregor | should probably be more polite in a publicly-logged channel, sorry to any readers who might have been offended |
| 09:20 | <workmad3> | :) |
| 09:21 | <Hixie> | AryehGregor: well i asked him to describe the user problem he's trying to solve, hopefully that will lead to him demonstrating that he isn't crazy and you just misunderstood him :-) |
| 09:21 | <workmad3> | oh wait... I just confused this one with the (very similar) discussion about <base> |
| 09:22 | <AryehGregor> | If I totally misunderstood him after like an hour-long IRC argument, good luck on that. |
| 09:23 | <workmad3> | I *think* I can see the rationale behind the idea... basically allowing you to link to RESTful sites by specifying the content type |
| 09:24 | <workmad3> | but I don't see the rationale behind doing it all through one <link> tag... that just seems overcomplicated. Just specify a couple of <link> tags with different content types and pointing to the same URL |
| 09:24 | <AryehGregor> | The idea of returning an HTML page or an RSS feed from the same URL is crazy. |
| 09:24 | <workmad3> | couple that with the fact that multiple <link> tags already works and multiple type attributes on a <link> tag will break older browsers... |
| 09:25 | <AryehGregor> | If you want to link to them or use them differently in any user-visible way, then they're different resources. |
| 09:26 | <workmad3> | AryehGregor: both views have weight unfortunately... although I agree that if they are both of relevance to a user then they should be distinguished in a user-visible way |
| 09:26 | <AryehGregor> | Actually, content negotiation ends up not being very useful altogether, even when used for its intended purpose. At least in general web development, maybe not in some other uses of HTTP. |
| 09:26 | <workmad3> | as opposed to it being hidden behind some web service call that is :) |
| 09:27 | <workmad3> | still, if the guy wants to do this, a mechanism already exists (multiple <link>s) and the way he is suggesting just overcomplicates things and breaks backwards compatibility |
| 09:29 | <workmad3> | and HTML on the 'human web' shouldn't need to get confused with support for RESTful web services |
| 09:30 | <AryehGregor> | Not sure how REST works, but does it care about <link> in HTML documents? |
| 09:30 | <workmad3> | the REST principles don't |
| 09:30 | <workmad3> | but a RESTful web service can be 'correct' to those principles and work like the guy is suggesting (so the rss feed and the html page are just 2 representations of the same resource) |
| 09:32 | <workmad3> | so it's not so much that they care about <link>s, more that multiple type's can be blugeoned into looking like REST support... if that makes sense and I'm not sounding as crazy as the original guy :) |
| 09:51 | <hsivonen> | sigh. the autobuffer thread just keeps growing |
| 10:00 | <annevk> | hsivonen, not in my inbox |
| 10:01 | annevk | lets foolip deal with it :) |
| 10:18 | <hsivonen> | Hixie: maybe boolean attributes should be called something other than boolean |
| 10:18 | <hsivonen> | Hixie: since it seems people assume they take values true and false |
| 10:18 | <hsivonen> | too late to change the language design pattern itself at this point, of course |
| 10:18 | <hsivonen> | and ARIA really doesn't help by failing to use the pre-existing design pattern |
| 10:21 | <annevk> | othermaciej, why would a non-normative guide be taken to Last Call? |
| 10:21 | <annevk> | othermaciej, typically they're published as W3C Note |
| 10:28 | <othermaciej> | annevk: good point |
| 10:28 | <othermaciej> | annevk: does the W3C ever publish non-normative references or "primer" type guides as REC instead of Note? |
| 10:29 | <annevk> | maybe they have actually |
| 10:29 | <othermaciej> | I found at least one example: http://www.w3.org/TR/2009/REC-owl2-primer-20091027/ |
| 10:30 | <annevk> | yeah http://www.w3.org/TR/rdf-primer/ |
| 10:30 | <othermaciej> | but I also found many examples that are Notes |
| 10:31 | <annevk> | should've remembered that I guess |
| 10:31 | <annevk> | but I'm not sure why we'd bother with the additional hassle if it's not at all needed |
| 10:32 | <othermaciej> | I'm not sure if the TAG overlooked this, or if they specifically want it to end up a non-normative REC instead of a Note |
| 10:33 | <Hixie> | hsivonen: file a bug |
| 10:34 | <hsivonen> | Hixie: I will after lunch. gotta go now |
| 10:38 | <annevk> | presence attributes |
| 10:50 | <Lachy> | flag attributes might be a better name |
| 10:56 | <Lachy> | it sucks that we have contenteditable, spellcheck and draggable=true/false, but inconsistently have autocomplete=on/off |
| 10:57 | <annevk> | spellcheck should have been on/off too |
| 10:58 | <annevk> | because it and autocomplete are about turning things off |
| 10:59 | <jgraham> | autocomplete=true would have been fine |
| 11:00 | <Hixie> | contenteditable and autocomplete were decided long before html5 was written |
| 11:00 | <Hixie> | so we were screwed either way |
| 11:00 | <Lachy> | yeah, I know that |
| 11:00 | <annevk> | no |
| 11:00 | <annevk> | we could've done spellcheck as on/off |
| 11:00 | <annevk> | but we didn't |
| 11:00 | <Hixie> | and had 2 and 2? |
| 11:00 | <Hixie> | that |
| 11:00 | <Hixie> | is even worse |
| 11:00 | <Hixie> | imho |
| 11:00 | <annevk> | no, they have different purposes each |
| 11:01 | <Hixie> | *shrug* |
| 11:01 | <Hixie> | actually by the time i added spellcheck it already had 2 implementations iirc |
| 11:01 | <othermaciej> | contentEditable and draggable are phrased as adjectives but also have the purpose of turning on/off |
| 11:01 | <Lachy> | if we introduce a buffering attribute, would buffering=on/off or true/false be better? Or should we go with none/auto/full as foolip suggested? |
| 11:01 | <annevk> | I think you might actually be the first that positioned the whole thing as such |
| 11:01 | <Hixie> | yeah i originally wrote it as a draft on damowmow.com |
| 11:01 | <othermaciej> | I would suggest not using on/off or true/false as the values if it has more than 2 states (which it should) |
| 11:02 | <annevk> | I meant the distinction between the attributes, not spellcheck (though you did that too) |
| 11:02 | <Hixie> | Lachy: last i looked at the thread it didn't seem that there was a strong use case for anything different than what the spec says now, but i have only skimmed so far |
| 11:02 | <Lachy> | othermaciej, draggable has 3 states and uses true and false, and omitted as the 3rd state |
| 11:02 | <Hixie> | it's all in my video bucket |
| 11:02 | <jgraham> | Wouldn't "missing attribute" do for the auto state? |
| 11:03 | jgraham | hasn't caught up[ on the thread yet |
| 11:04 | <othermaciej> | Lachy: that's true - I'm not sure there needs to be an explicit way to say the same as the omitted state |
| 11:04 | <othermaciej> | I will try to summarize the thread into a bug when it settles down |
| 11:04 | <Lachy> | Hixie, if we keep the spec as is, then having autobuffer omitted must then mean no buffering. But that doesn't allow for browsers to provide sensible heuristic based approaches |
| 11:05 | <othermaciej> | what Lachy said - I think there needs to be a way to specifically hint "don't buffer" that's distinct from giving no hint at all |
| 11:05 | <Hixie> | what's the use case for that? |
| 11:06 | <jgraham> | "authors really want to conserve bandwidth" |
| 11:06 | <Lachy> | the main use case mentioned on the list has been a blog that includes a video as part of one of the entires, but the author doesn't think all users will want to watch the video just because the article still happens to be on the front page |
| 11:06 | <Hixie> | wouldn't that be all authors who don't want buffering? |
| 11:06 | <jgraham> | Hixie: ? |
| 11:07 | <Hixie> | what's the distinction between the author who doesn't want buffering (and so doesn't set autobuffer) and the author who wants no buffering (and so sets nobuffer)? |
| 11:07 | <zcorpan_> | MikeSmithX: <style><!--> opens an escape in opera |
| 11:08 | <jgraham> | Hixie: The author that doesn't set autobuffer may still get buffering if the browser so choses |
| 11:08 | <Lachy> | the difference is that the omitted attribute doesn't give a clear indication of author preference, and so browsers should be allowed to optimise for the best user experience |
| 11:09 | <othermaciej> | Hixie: authors who don't think about the issue likely won't include any particular attribute, thus the browser might choose to guess whether buffering would be good based on things like number of videos on the page, their prominence and relative size, etc |
| 11:10 | <Lachy> | e.g. If I'm on a high speed connection with no bandwidth limits, as I am here in Norway, then I wouldn't mind having my browser autobuffer for me automatically on most sites. However, if I'm stuck in Australia on a slow, usage-capped connection then I'd prefer not to unless I really wanted to watch the video |
| 11:10 | <othermaciej> | Hixie: except that you can't distinguish "no opinion" from "specifically don't want buffering" |
| 11:10 | <othermaciej> | with the current spec design |
| 11:10 | <doublec> | how would the browser know you're on a usage capped connection? |
| 11:10 | <Hixie> | jgraham: the author who does set an explicit nobuffer may still get buffering if the browser so choses |
| 11:10 | <Lachy> | doublec, probably user preference |
| 11:11 | <Hixie> | Lachy: browsers should always be allowed to optimise for the best user experience, whatever attributes are set |
| 11:11 | <Hixie> | othermaciej: is that a hypothetical or are browsers really doing that? |
| 11:11 | hsivonen | considers pay per byte deals a bug |
| 11:12 | <othermaciej> | Hixie: I'd like to make Safari do that, if I could |
| 11:12 | <doublec> | I'm a fan of no attribute - author doesn't want to buffer, with attribute = author does want to buffer, and the browser can override if it feels necessary |
| 11:12 | <Philip`> | hsivonen: What about pay-per-month-with-3GB-per-month-cap? |
| 11:12 | <doublec> | but on the html mail list authors seemed to think this wasn't a good idea |
| 11:12 | <othermaciej> | if the spec remains as-is, then we'll probably either always buffer for autobuffer and never buffer when it's missing |
| 11:12 | <hsivonen> | Philip`: I consider that a bug, too |
| 11:12 | <othermaciej> | (unless we know we're on a limited connection or constrained-resource device in which case never buffer at all) |
| 11:12 | <Philip`> | hsivonen: (That and pay-per-byte seem to be the only mobile internet services available here) |
| 11:12 | <hsivonen> | Philip`: I approve of capping per second bandwidth, though |
| 11:12 | <jgraham> | Hixie: It seems reasonable to make that behaviour non-conforming as it may have a disproportionate impact on the authouring side (making bandwidth bills too high is <video> is used) so encouraging people to use a solution that doesn't allow unrequested autobuffering |
| 11:12 | <Lachy> | Hixie, sure, but that doesn't give the author an opt-out to conserve their own bandwidth. e.g. If I visit a site that embed's a video without specifying autobuffer, and my personal user preferences is to automatically buffer the video anyway, that doesn't allow the author to tell the browser not to |
| 11:13 | hsivonen | pays 9.90 EUR per month for 384 Kb/s without other caps |
| 11:14 | <hsivonen> | HSDPA/UMTS/EDGE/GPRS as supported by the tower |
| 11:14 | <Hixie> | well i'm very skeptical, but if implementations are going to use it i guess we can change autobuffer from a boolean attribute to autobuffer=always/never/etc (i.e. maybe adding other values in the future) |
| 11:14 | <Hixie> | with the lack of an attribute being the "auto" case |
| 11:15 | <Hixie> | seems pretty silly though, why would anyone use a host where bandwidth was an issue? |
| 11:15 | <hsivonen> | Hixie: so autobuffer=never would buffer more than the lack of the attribute in Firefox 3.5 |
| 11:15 | <hsivonen> | Hixie: seems like a pretty big fail |
| 11:15 | <doublec> | yes, you'd probably need to change the name |
| 11:15 | <Hixie> | hsivonen: doesn't matter, nobody is going to use video for ages anyway, plenty of time for ff4 to replace ff3.5 |
| 11:15 | <doublec> | I still have a fair proportion of users watching video using Firefox 3.1 believe it or not |
| 11:15 | <doublec> | according to my logs |
| 11:16 | <adactio> | Just a reminder: this isn't just about video, it's also about audio (which I *would* like to use today). |
| 11:16 | <hsivonen> | Hixie: "ages" gets longer every time you move the earliest client deployment forward |
| 11:16 | <Hixie> | use of either audio or video is not going to take off until we have a common codec |
| 11:16 | <Hixie> | everything until then is peanuts |
| 11:16 | <zcorpan_> | can't we leave autobuffer alone and fix the bug in webkit? |
| 11:16 | <hsivonen> | aside: what's up with the On2 shareholders voting to adjourn repeatedly? |
| 11:17 | <jgraham> | zcorpan_: That is necessary but not sufficient |
| 11:17 | <hsivonen> | so much for getting the news in 2009Q4 |
| 11:17 | <Hixie> | anyway it's way past my bedtime |
| 11:17 | Philip` | uses a host with 30KB/s upload bandwidth because it's convenient to run a box at home, and wouldn't want people unnecessarily using up that bandwidth |
| 11:17 | <Hixie> | nn :-) |
| 11:17 | <adactio> | Hixie: not necessarily ...because I can put fallback content (such as a Flash player) inside the <audio> tags, the element is usable today, even if it isn't implemented in all browsers ...but the autobuffering question is the big sticking point. |
| 11:17 | <Lachy> | Hixie, consider YouTube providing embed code to authors, as they do now. I'm sure Google wouldn't want every page to begin auto buffering their videos. Currently, YouTube videos don't autobuffer on 3rd party sites. |
| 11:17 | <zcorpan_> | it's easy to say "no autobuffer": don't include the <video> at all |
| 11:17 | <zcorpan_> | until you want to play it |
| 11:18 | <jgraham> | zcorpan_: Well yes if you want to fuss about with js every time you include a video |
| 11:18 | <Philip`> | zcorpan_: Or use Flash |
| 11:18 | <Lachy> | zcorpan_, that requires mildly complex scripts to work around a bug that should be easily solveable with markup |
| 11:18 | <Philip`> | Those solutions harm the user experience, though |
| 11:18 | <jgraham> | Not really compatible with "copy this small fragment of markup to embed this video" |
| 11:30 | <annevk> | http://virtualdub.org/blog/pivot/entry.php?id=293 |
| 11:31 | <annevk> | I had a similar experience trying to write an XML parser |
| 11:32 | smaug_ | likes the comment "First, it's so much easier to work off of a spec that essentially fits on one page and doesn't have spaghetti hyperlinks" ;) |
| 11:34 | <annevk> | sniping from the sideline is easy; where's your spec? |
| 11:35 | <annevk> | :) |
| 11:35 | <workmad3> | yes, it's a lot easier to work off a spec that fits on one page |
| 11:35 | <workmad3> | normally because something that can be specced in one page is fairly simple to do :P |
| 11:37 | <Philip`> | Something that is specced in many more pages isn't necessarily inherently harder to do |
| 11:38 | <Philip`> | It might be just be specced in an overly complex way for your requirements |
| 11:38 | <Philip`> | s/be// |
| 11:38 | <annevk> | the other points in the post are the more interesting ones imo |
| 11:38 | <Philip`> | (Serialising a tree of strings really shouldn't be hard) |
| 11:40 | <workmad3> | Philip`: true, good points all |
| 11:41 | <workmad3> | I just find it funny when people come across things that are complex and complain that they are then difficult to implement... as if that wasn't frickin' obvious :) |
| 11:42 | <annevk> | well, for XML it isn't that obvious |
| 11:42 | <annevk> | because 50% of its features are almost never used |
| 11:43 | <workmad3> | true |
| 11:43 | <annevk> | but are still required for conforming implementations |
| 11:44 | <hsivonen> | does JSON have a parsing spec now? |
| 11:44 | <hsivonen> | regardless of whether the parsing spec fits on a page or has hyperlinks |
| 11:45 | <annevk> | I am a bit scared by his assertion that JSON mandates UTF-32 |
| 11:45 | <annevk> | I hope that's a mistake |
| 11:47 | <workmad3> | annevk: I think he meant that the JSON parser spec mandates that the parser be able to understand UTF-32 |
| 11:47 | <workmad3> | not that all JSON should be in utf-32 :) |
| 11:47 | <annevk> | Opera recently killed UTF-32 support |
| 11:47 | <workmad3> | hmm... lunch time |
| 11:47 | <hsivonen> | workmad3: what's "the parser spec"? |
| 11:47 | <annevk> | HTML5 recommends against UTF-32 |
| 11:48 | <annevk> | and http://tools.ietf.org/html/rfc4627 mentions UTF-32 including how to detect it but does not seem to require it... |
| 11:48 | <workmad3> | http://www.ietf.org/rfc/rfc4627 <-- rfc for it |
| 11:48 | <workmad3> | there's also apparently a slightly different spec for JSON in the ECMAScript 5 spec |
| 11:48 | <annevk> | but then it never requires UTF-8 support or UTF-16 either |
| 11:48 | <hsivonen> | workmad3: looks like a partial syntax spec to me |
| 11:48 | <annevk> | maybe it does not have UA requirements |
| 11:48 | <hsivonen> | workmad3: see section 4 for spectacular underspecification |
| 11:51 | <annevk> | section 4 assumes the input stream is in Unicode |
| 11:51 | <annevk> | or something |
| 11:51 | <annevk> | so no encoding requirements there either |
| 11:51 | <Lachy> | annevk, section 3 also specifies "JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.", so I guess that assumption is section 4 is reasonable |
| 11:52 | <Lachy> | though, it mentions nothing about what to do with non-conforming streams |
| 11:52 | <annevk> | no, I mean that it assumes it is a character stream rather than a byte stream |
| 11:53 | <annevk> | there's no requirements about bytes to characters afaict |
| 11:56 | <jgraham> | FWIW I would regard the ES5 version of JSON as being "correct" rather than the RFC in as much as the differences are deliberate and reagrded as bug fixes |
| 11:56 | <jgraham> | (but that is, I guess, less likely to be helpful with encoding issues) |
| 12:30 | <gsnedders> | Well, the ES5 section assumes the same as the rest of ES5 wrt to text: you get an abstract Unicode stream with UTF-16 surrogates somehow. |
| 12:31 | <hsivonen> | jgraham: does ES5 say what to do with stream that don't match the grammar? |
| 12:39 | <gsnedders> | hsivonen: It throws SyntaxError |
| 12:41 | <jgraham> | gsnedders: Right so it doesn't really cover standalone json |
| 12:42 | <gsnedders> | Right, it defines the grammar, and the JSON object in ES |
| 12:42 | <hsivonen> | gsnedders: what about the open-ended permission to accept extensions in the RFC? does ES5 plug that hole? |
| 12:43 | <gsnedders> | hsivonen: For JSON.parse, anything that doesn't match the grammar throws SyntaxError, so for JSON.parse, yes. |
| 12:44 | <hsivonen> | cool |
| 12:44 | <gsnedders> | Speaking of ES, anyone found any bugs in Carakan? |
| 12:58 | <jgraham> | gsnedders: I have :) |
| 12:58 | <gsnedders> | jgraham: NO WAI. |
| 13:16 | <Philip`> | gsnedders: Yes, but when I told you you told me you'd already tested everything, so I stopped looking :-p |
| 13:19 | <jgraham> | Philip`: You didn't tell me |
| 13:20 | <jgraham> | (or maybe you did and I just didn't read the logs) |
| 13:26 | <gsnedders> | jgraham: He told me and I said it was known |
| 13:28 | <hsivonen> | so now there's a bug saying that extensibility is bad for accessibility: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8619 |
| 13:28 | <hsivonen> | (I agree, FWIW, that extenders making stuff up is bad for accessibility) |
| 13:29 | <zcorpan> | accessibility is bad for extensibility! |
| 13:30 | <annevk> | it's not exactly clear what part of that section 8619 is addressing |
| 13:30 | <annevk> | the issue marker? |
| 13:32 | <MikeSmithXX> | zcorpan: so you don't want "<style><!--></style>" to be conforming, right? |
| 13:33 | <zcorpan> | MikeSmithXX: right |
| 13:34 | <MikeSmith> | zcorpan: so you want a warning reported for <title><!--</title> and <textarea><!--</textarea> ? |
| 13:36 | <zcorpan> | MikeSmith: yes |
| 13:36 | <zcorpan> | MikeSmith: but not for <title><!--</title> |
| 13:37 | <hsivonen> | ouch |
| 13:37 | <annevk> | anyone have some charset tables handy? |
| 13:37 | <annevk> | if you send a FF byte through a HTTP header and it comes out as C3 BF |
| 13:37 | <annevk> | what happened? |
| 13:38 | <MikeSmith> | oh, <!-- is a problem |
| 13:38 | <annevk> | decoded as UTF-8 |
| 13:38 | <annevk> | that's what happened |
| 13:39 | <annevk> | maybe even transmitted as UTF-8 hmm |
| 13:41 | <annevk> | oh no duh |
| 13:41 | <MikeSmith> | zcorpan: I have a style-content checker live on qa-dev, including the title and textarea warnings |
| 13:42 | <annevk> | that's iso-8859-1 |
| 13:42 | <Philip`> | Validators really don't seem like an ideal place to practice clean separation of layers in software architecture |
| 13:43 | <Philip`> | since their function is to deal with user errors, and erroneous users don't cleanly separate layers |
| 13:44 | <MikeSmith> | heh |
| 13:48 | <annevk> | bah |
| 13:48 | <annevk> | it seems iso-8859-1 is used in browsers for HTTP |
| 13:48 | <annevk> | instead of windows-1252 everywhere |
| 13:48 | <annevk> | lame |
| 13:49 | <gsnedders> | Opera trims on \x00 with HTTP headers |
| 13:49 | <annevk> | all browsers do |
| 13:49 | <annevk> | or maybe it's my server that does |
| 13:50 | <gsnedders> | Only Opera does. |
| 13:50 | gsnedders | has tests for this |
| 13:50 | <gsnedders> | Probably server. |
| 13:50 | <gsnedders> | I had to write my own server to test a fair bit of stuff |
| 13:50 | <zcorpan> | MikeSmith: nice |
| 13:52 | <annevk> | gsnedders, hmm |
| 13:53 | <MikeSmith> | zcorpan: well, except failing for <!-- and --> of course |
| 13:54 | <annevk> | gsnedders, guess you're right |
| 13:54 | <annevk> | but then testing 00 is not really needed |
| 13:54 | <annevk> | WebKit is buggy here btw |
| 13:54 | <annevk> | or whatever HTTP impl Chrome is using is buggy |
| 13:55 | <zcorpan> | MikeSmith: and it checks in xhtml, which is a bit bogus (but per spec, i filed a spec bug iirc) |
| 13:55 | <gsnedders> | WebKit has no HTTP impl in it itself |
| 13:55 | <gsnedders> | That's platform specific |
| 13:55 | <annevk> | right |
| 13:55 | <gsnedders> | Chrome has its own |
| 13:55 | <annevk> | anyway, it's buggy |
| 13:55 | <annevk> | not necessarily platform |
| 13:55 | <gsnedders> | How so? |
| 13:55 | <annevk> | browser-specific |
| 13:55 | <gsnedders> | Well, WebKit port specific. |
| 13:55 | <annevk> | it decodes http using utf-8 or so |
| 13:56 | <gsnedders> | If they can get away with that, that's very interesting. |
| 13:56 | <annevk> | dunno |
| 13:56 | <hsivonen> | Opera 10.50 <video> support doesn't work nicely with Wikipedia :-( |
| 13:56 | <gsnedders> | I doubt it uses UTF-8 for everything |
| 13:56 | <annevk> | but FF ends up as EF BF BD rather than C3 8D |
| 13:57 | <hsivonen> | aside: shipping gstreamer with Opera on Windows looks like a pretty significant change to the previous way of Opera implementing everything from scratch in-house |
| 13:57 | <annevk> | and similar story for other characters above 7E |
| 13:57 | <annevk> | hsivonen, not really |
| 13:58 | <annevk> | hsivonen, though some things have changed I guess, we used to have an open source XML parser |
| 13:58 | <annevk> | we still use various external sources, but no longer that XML one |
| 13:58 | <hsivonen> | ok |
| 13:59 | <annevk> | OpenSSL and Zlib are prolly somewhat well-known |
| 13:59 | <gsnedders> | FreeType stuff is there too |
| 13:59 | <hsivonen> | gsnedders: on Windows? |
| 13:59 | <gsnedders> | Dunno. I'm just looking at opera:about ;P |
| 14:01 | <hsivonen> | whoa. the menubar is gone in Opera 10.50 on Windows |
| 14:02 | <annevk> | also on Linux |
| 14:02 | <hsivonen> | Java seems to make Opera 10.50 on Windows awfully slow |
| 14:02 | <gsnedders> | I thought Java didn't work at all in 10.50 currently. |
| 14:02 | <hsivonen> | I wonder if using the cortado fallback for <video> is a good idea anymore |
| 14:03 | <hsivonen> | gsnedders: well, at least I think I had an applet in the tab I just closed |
| 14:04 | <hsivonen> | no tab resurrection with ctrl-shift-t it seems :-( |
| 14:05 | <hsivonen> | apparently the tab I thought had cortado in it instead was playing <video> without reaching cortado |
| 14:06 | <hsivonen> | what happened to the idea of making an Ogg/Theora/Vorbis/<video> signed ActiveX control for IE? |
| 14:19 | <gsnedders> | hsivonen: ctrl-z should undo closing tabs |
| 14:20 | <hsivonen> | gsnedders: that's an odd use of ctrl-z! |
| 14:21 | <MikeSmith> | maybe for reporting on "<!--" in <style> it can only reported as a warning, "Content *appears to* contain the character sequence <!-- without a later occurrence of the character sequence -->" |
| 14:22 | <Huvet> | ok, I'm definately going crazy... can't I make html5lib remove everything but divs when parsing? |
| 14:22 | <Huvet> | there's some kind of patch here: http://code.google.com/p/html5lib/issues/detail?id=62 |
| 14:22 | <hsivonen> | MikeSmith: do you mean title and textarea? |
| 14:22 | <MikeSmith> | hsivonen: yeah |
| 14:22 | <Huvet> | but that seems rejected, and the fifth comment posts some code, that I can't get to work |
| 14:23 | <MikeSmith> | I guess it's a warning already.. myabe just need to tweek the wording |
| 14:24 | <MikeSmith> | hsivonen: hmm, what about the case of <style> also? |
| 14:25 | <hsivonen> | MikeSmith: in style it could be straightforward to implement it as an error, right? |
| 14:26 | <MikeSmith> | I just tested and "<" is getting interpreted by v.nu as "<" |
| 14:26 | <MikeSmith> | in style also |
| 14:26 | <hsivonen> | whoa |
| 14:26 | <hsivonen> | that's a bug |
| 14:27 | <MikeSmith> | seems so |
| 14:28 | <hsivonen> | odd. I don't see the bug in Gecko |
| 14:33 | <MikeSmith> | hsivonen: maybe a problem in how I implemented the check? |
| 14:34 | <annevk> | hsivonen, what would you use instead of ctrl+z ? |
| 14:34 | <annevk> | i learned it by trying ctrl+z :) |
| 14:34 | <TabAtkins> | annevk: Alt+Home, and click on "Recently Closed Tabs". |
| 14:35 | <hsivonen> | MikeSmith: that's possible |
| 14:35 | <hsivonen> | annevk: ctrl-shift-t :-) |
| 14:35 | <MikeSmith> | hsivonen: because when I test with http://c.validator.nu/debug/ set, I get "Warning: Characters: <--." as expected, instead of "Warning: Characters: <". |
| 14:36 | <hsivonen> | I expect ctrl-z to undo the last modification I've made to the content of the frontmost tab |
| 14:36 | <hsivonen> | MikeSmith: very odd |
| 14:36 | <hsivonen> | MikeSmith: it's possible that V.nu and Gecko are out of sync |
| 14:36 | <annevk> | TabAtkins, ctrl+z seems easier |
| 14:36 | <annevk> | hsivonen, heh |
| 14:37 | <MikeSmith> | hsivonen: fwiw, I just implemented it using the existing TextContentHandler and corresponding new datatype |
| 14:37 | <TabAtkins> | annevk: But what if you're editting a textarea in that tab? Then there's a conflict in what should be Undone. |
| 14:37 | <MikeSmith> | and the new datatype class just gets the character stream same as any other |
| 14:38 | <annevk> | they don't need to be mutually exclusive |
| 14:38 | <annevk> | e.g. tabs could just be put on the stack |
| 14:38 | <annevk> | not sure how it actually works in Opera |
| 14:38 | <annevk> | I only ever use it when I press ctrl+w per accident |
| 14:39 | <annevk> | (Opera puts them on a stack) |
| 14:39 | <gsnedders> | TabAtkins: They're both just events in the stack |
| 14:39 | <gsnedders> | TabAtkins: There's nothing magic about tabs being closed |
| 14:39 | <annevk> | (though some things are global-stack and some are page-stack) |
| 14:40 | jgraham | has a weird mix of expectations about how undo close tab should work |
| 14:41 | <TabAtkins> | gsnedders: (a) what Anne just said about the different stacks. (b) There's still a mental conflict. If I close something and then turn to my textarea and realize I need to undo what I just wrote, I'll be surprised when I reopen the old tab. |
| 14:41 | <jgraham> | I think I expect a unique undo command for tabs but avaliable from the edit menu |
| 14:43 | gsnedders | wants how to cope with TOCs is different forms in Anolis |
| 14:43 | <gsnedders> | s/wants/wonders/ |
| 14:44 | <gsnedders> | Like, coping with multi-file TOCs, single-file TOCs, TOCs just for the current section, just of one level... |
| 14:44 | <gsnedders> | TOCs just for the current section I think I can probably ignore |
| 14:49 | <jgraham> | gsnedders: Why do you need any of that? |
| 14:50 | <gsnedders> | Also, if anyone is interested, html5lib tip is no quicker at parsing the complete spec in unladen than it is in normal CPython |
| 14:51 | <gsnedders> | jgraham: Multi-doc TOC: see http://w3.org/TR/CSS21/; just for a certain section: see some section of CSS 2.1, the TOC in HTML 5 |
| 14:51 | <jgraham> | gsnedders: We should put together a benchmark and then try to get the unladen people to use it ;) |
| 14:51 | <gsnedders> | Flexibility of depth: see the short TOC in HTML 5 |
| 14:52 | <zcorpan> | hsivonen: what doesn't work nice with video on wikipedia? |
| 14:52 | <hsivonen> | zcorpan: clicking the browser-native play button doesn't start playing soon |
| 14:53 | <hsivonen> | then if I come back later, the video has played to the last frame, but pressing the button again doesn't restart it |
| 14:53 | <zcorpan> | the latter issue is probably because seeking doesn't work yet |
| 14:53 | <hsivonen> | ah |
| 14:54 | <zcorpan> | is there a url i can use to test the first issue? |
| 14:55 | <hsivonen> | zcorpan: http://en.wikipedia.org/wiki/Groundhog |
| 14:55 | <hsivonen> | hmm. it could be a server problem |
| 14:55 | <hsivonen> | but Firefox gives more useful feedback while it is waiting for the server |
| 14:56 | <zcorpan> | indeed |
| 14:57 | <zcorpan> | (it plays fine for me) |
| 15:00 | <zcorpan> | MikeSmith: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8567 was the spec bug |
| 15:02 | MikeSmith | looks |
| 15:03 | <zcorpan> | MikeSmith: can't <!-- checking be in the tokenizer instead? |
| 15:04 | <hsivonen> | zcorpan: it could--by adding more states |
| 15:04 | <zcorpan> | true |
| 15:05 | gsnedders | fixes more issues in html5lib |
| 15:05 | <zcorpan> | might also get messy with the <!--> thing |
| 15:05 | <MikeSmith> | but it seems like it would be only useful for conformance checkers, not for other uses of the tokenizer/parser |
| 15:05 | <jgraham> | gsnedders: I have a local patch that fixes something |
| 15:06 | <jgraham> | I just don't recall what |
| 15:06 | <jgraham> | (not the thing that you just pushed at least) |
| 15:06 | <zcorpan> | i don't care overly about title/textarea; checking script and style is most important |
| 15:07 | <zcorpan> | my research showed that people don't use <!-- in title or textarea, so it might be pointless to check them |
| 15:10 | <jgraham> | gsnedders: Oh it was to raise a DeprecationWarning when the BS treebuilder is used |
| 15:11 | <gsnedders> | Ah |
| 15:14 | <annevk> | how the hell do you get access to request headers in python? |
| 15:15 | <annevk> | where is the basic http interaction tutorial that does not involve making requests from Python? |
| 15:15 | <annevk> | i can never find it |
| 15:15 | <annevk> | never |
| 15:15 | annevk | is just a little frustrated with his lack of luck |
| 15:15 | <annevk> | I could do it in PHP, but I wanna move away from that at some point... |
| 15:16 | <jgraham> | Well if you need the raw unprocessed stuff and are using CGI you presumably want os.environ |
| 15:24 | <annevk> | and how do you get headers out of that? |
| 15:24 | <annevk> | environment variables do not exactly appear to be documented :/ |
| 15:24 | <annevk> | os.environ has not a single pointer ?! |
| 15:26 | <Philip`> | CGI doesn't pass raw unprocessed stuff |
| 15:26 | <Huvet> | can I trust that the document is properly nested (all StartTags have an EndTag) in a subclass to HTMLSanitazion (while overriding sanitize_token)? |
| 15:27 | <Philip`> | It just gives you environment variables like HTTP_CONTENT_TYPE and HTTP_X_FOO_BAR etc, parsed from the headers |
| 15:27 | <Huvet> | hmm... I guess not... because only the tree I get from html5lib is properly nested... |
| 15:27 | <Huvet> | i guess |
| 15:28 | <annevk> | Philip`, if I set a header test I do not get it back with HTTP_TEST |
| 15:29 | <annevk> | or HTTP_test or HTTP_X_TEST |
| 15:29 | <gsnedders> | Huvet: Dunno whether <img> will give both |
| 15:29 | <Philip`> | Huvet: Sounds like that's working at the tokenizer level, so there's no nesting fixups or guarantees |
| 15:30 | <Huvet> | thanks, that figures |
| 15:30 | <Philip`> | annevk: What if you set a header X-Test? |
| 15:30 | <annevk> | never mind |
| 15:30 | <annevk> | I fail |
| 15:30 | <annevk> | forgot to import os |
| 15:30 | <annevk> | though also Python fail for not throwing server errors |
| 15:31 | <annevk> | imo |
| 15:31 | <annevk> | cheerio |
| 15:31 | <MikeSmith> | hsivonen: fyi, the problem was I was seeing with <!-- was just a stupid oversight in the code I added |
| 15:31 | <MikeSmith> | fixed now |
| 15:31 | <MikeSmith> | sorry for the noise |
| 15:31 | <Philip`> | annevk: import cgitb |
| 15:31 | <Philip`> | or something like that |
| 15:31 | <Philip`> | to get error reports |
| 15:32 | <gsnedders> | jgraham: So, we need some file that takes a second or two to parse |
| 15:32 | <Philip`> | gsnedders: I suggest the first n lines of the HTML5 spec |
| 15:34 | MikeSmith | takes a break |
| 15:34 | <hsivonen> | MikeSmith: ok |
| 15:36 | <MikeSmith> | hsivonen: btw, what's the rationale for having the error messages in TextContentHandler also report the namespace? |
| 15:36 | <MikeSmith> | e.g., "The text content of element style from namespace http://www.w3.org/1999/xhtml was not in the required format" |
| 15:36 | <hsivonen> | MikeSmith: consistency with way Jing reports stuff, IIRC |
| 15:37 | <jgraham> | import cgitb; cgitb.enable() |
| 15:37 | Philip` | wonders if somebody is going to make a user-friendly validator frontend that gives more understandable error messages |
| 15:37 | <MikeSmith> | hsivonen: I see |
| 15:38 | <jgraham> | But you will get errors in /var/log/apache2/error.log or similar if the import failed |
| 15:38 | <MikeSmith> | but it's not consistent with how v.nu reports stuff |
| 15:39 | <annevk> | for setRequestHeader() it seems browsers just go for UTF-8 octets? |
| 15:39 | <annevk> | hmm |
| 15:39 | <Philip`> | (Seems like there's an opportunity to match the low-level validator output against patterns from common user errors, and give more high-level advice about what the problem is and how to fix it) |
| 15:44 | <MikeSmith> | Philip`: that would involve some guessing about the root cause of the user error, right? |
| 15:46 | <MikeSmith> | Philip`: anyway, if I understand you correctly, hsivonen has some of that already in the htmlparser error messages |
| 15:47 | <Philip`> | MikeSmith: Call it "heuristics" rather than "guessing" :-) |
| 15:47 | <MikeSmith> | heh |
| 15:47 | <Philip`> | and have it informed by statistics |
| 15:48 | <MikeSmith> | Philip`: first part of many htmlparser error messages reports what the actual error is, then the last part reports, "Probable cause: ..." |
| 15:49 | <Philip`> | MikeSmith: Is that ever based on patterns of more than one error message? |
| 15:50 | <MikeSmith> | Philip`: no, I don't think so, not currently |
| 15:50 | Philip` | hasn't actually used the validator enough to know whether those problems occur much and could be reported better, so he's just making this all up and could be completely wrong |
| 15:51 | Philip` | imagines it's harder when you have to actually implement it |
| 15:51 | <MikeSmith> | basing reporting on patterns of more than one error condition would seem to require keeping a lot of state information around about what errors have already occurred |
| 15:52 | <Philip`> | Sure |
| 15:52 | <Philip`> | Memory is cheap :-) |
| 15:52 | <MikeSmith> | heh |
| 15:53 | <MikeSmith> | OK, I gotta get some food |
| 15:53 | <MikeSmith> | bbiab |
| 16:26 | <MikeSmith> | Philip`: what you describe could be implemented in a third-party app that consumes output from v.nu |
| 17:13 | <abernier> | html5 introduces new elements like <header>, <footer>, <nav>, ... is it a good idea for html4 authoring to replace them by <div class="(header|footer|nav)" ? |
| 17:31 | <AryehGregor> | abernier, doesn't really matter, unless it will make transition easier or something. |
| 17:32 | <AryehGregor> | abernier, the point of the new elements is to add standardized semantics, you don't get those in HTML4 for these elements either way. |
| 17:33 | <abernier> | AryehGregor: yes, and adding semantics through class attributes is a quite common concept, no? |
| 17:42 | <AryehGregor> | abernier, but they aren't standardized semantics. Nothing other than your own page is going to treat <div class="header"> any differently from <div class="snafflefloozer">. For all any third-party semantics-inferring tool knows, you prefer to call your headers snafflefloozers and vice versa. So there's no reason to use one over the other except personal preference/legibility/etc. |
| 17:56 | <AryehGregor> | I know users underestimate how much effort development takes, but this is still a pretty impressive statement: ". . . I want everything perfect and without any flaws. Is that to much to ask ?" http://code.google.com/p/chromium/issues/detail?id=16482 |
| 18:07 | AryehGregor | supposes that when open-source software takes over the world, users will interact with developers more and have a better understanding of how much effort it takes to implement something well. |
| 18:51 | <smaug_> | so what is the current way to get changes to the draft; do I always need to file bugs @w3c or is the old way (send email to whatwg) still enough? |
| 18:51 | <smaug_> | Hixie: ^^^ |
| 18:57 | <gsnedders> | smaug_: either |
| 18:57 | <smaug_> | ok, thanks |
| 19:12 | <jgraham> | gsnedders: BTW I know a blog engine that always uses a proper serializer |
| 19:12 | <gsnedders> | jgraham: NAmely? |
| 19:12 | <jgraham> | http://code.cmlenz.net/diva/wiki/Divan |
| 19:13 | <jgraham> | It fails on "easy to set up and use" though |
| 19:13 | <jgraham> | (but you didn't list those as requirments) |
| 19:14 | <jgraham> | (in particular you need an atompub client to create/edit entires) |
| 19:14 | <jgraham> | (and you need couchdb which is not trivial to run in all hosting situaions) |
| 19:17 | <Philip`> | "Seriously: You probably don't want to be using this." |
| 19:17 | <Philip`> | (on the framework for which Divan is an example application) |
| 19:17 | <Philip`> | That doesn't sound entirely promising |
| 20:32 | <gsnedders> | Oooo, MS have joined SVG WG. |
| 21:09 | <Dashiva> | "If I'm designing an XML vocabulary, I usually like to associate a namespace with my vocabulary, as it gives a feeling to me, that this vocabulary belongs to me" |
| 21:09 | <bfrohs> | Could someone give me insight as to why two margins are appearing? - http://frohsenwebdesign.com/projects/css3-tests/multiple-floats-and-margin.html |
| 21:10 | <AryehGregor> | bfrohs, what do you mean, two margins? |
| 21:11 | <bfrohs> | Go to the link (refresh if you went to immediately). I have a top margin of 50 px set to the second element in each group |
| 21:11 | <bfrohs> | It appears between the first and second element as well as above the first element |
| 21:11 | AryehGregor | is intrigued by the seemingly random use of <section> and <aside> instead of <div> here |
| 21:12 | <bfrohs> | It's from a website I'm working on... basically removed pieces of code until it was the bare minimum - didn't take the time to change things. |
| 21:13 | <AryehGregor> | What browser are you testing in? |
| 21:13 | <AryehGregor> | It looks very different between Firefox and Chrome. |
| 21:13 | <bfrohs> | Firefox 3.5, 3.6, and 3.7 on ubuntu |
| 21:13 | <bfrohs> | Yes, that's why I'm confused |
| 21:13 | <bfrohs> | Hoping someone has insight here |
| 21:14 | <AryehGregor> | Tried #css? |
| 21:14 | <bfrohs> | On freenode? |
| 21:15 | <AryehGregor> | Yes. |
| 21:15 | <AryehGregor> | Curious. |
| 21:15 | <bfrohs> | Nope - will do now. I'm not one to use IRC |
| 21:16 | <AryehGregor> | . . . you're using IRC. |
| 21:16 | <AryehGregor> | You can make a more minimal test case, by the way. |
| 21:16 | <AryehGregor> | A lot of the stuff you have is still extraneous. |
| 21:16 | <AryehGregor> | Would be easier to understand if you only had like three elements there, and a minimal set of rules. |
| 21:18 | <bfrohs> | The problem only occurs with floats - hence the multiple floats... and the first rules (before /*important*/) are purely cosmetic |
| 21:19 | <AryehGregor> | You can get rid of a lot of elements, like the .layout > aside. |
| 21:19 | <AryehGregor> | Would make things simpler to look at. |
| 21:19 | <jgraham> | cosmetics have no place in testcases :) |
| 21:19 | <AryehGregor> | You have relative positioning, etc., all extraneous. |
| 21:20 | <bfrohs> | Alright, thanks. I'll take care of that now :) |
| 21:21 | <Philip`> | Dashiva: If I'm designing an XML vocabulary, I like to prefix every element and attribute name with my name, so that I feel it belongs to me |
| 21:21 | <Philip`> | Also it means people can return it to me if I accidentally lose it somewhere |
| 21:22 | <Dashiva> | Philip`: Or if it's stolen |
| 21:23 | <Philip`> | Dashiva: It wouldn't help in that case, the thieves would just strip off the obvious identifying marks |
| 21:23 | <Dashiva> | But then it wouldn't be stealing |
| 21:23 | <Philip`> | That's why I also hide my name steganographically in the first letter of every element and attribute name in the vocabulary |
| 21:23 | <Dashiva> | Since they wouldn't be my elements anymore |
| 21:42 | <bfrohs> | If anyone wants an update to my problem from earlier regarding CSS in Firefox, it's a bug in the Gecko engine as far as anyone can tell. Thanks for the direction to #css ! :) |
| 21:46 | <jgraham> | bfrohs: I take it you will file a bug? :) |
| 21:46 | <jgraham> | (assuming there isn't one already) |
| 21:48 | <bfrohs> | jgraham: Aye, taking care of now. |
| 21:55 | <bfrohs> | jgraham: https://bugzilla.mozilla.org/show_bug.cgi?id=537808 if you want it fixed |
| 22:02 | <jwalden> | bfrohs: generally, when filing bugs, you should create a self-contained testcase and upload it to the bug; a URL might change in the future (even if it's something you control -- what if you forget about the external reference?), so it's important to capture exactly what was there for permanent reference -- mind doing that? |
| 22:02 | <egn> | hi, for an html5 media element, how would I signal it to stop buffering? |
| 22:02 | <jwalden> | inline external stylesheets, create data: URLs for images and such, etc. |
| 22:02 | <annevk> | not include the autobefuffer attribute |
| 22:02 | <bfrohs> | jwalden: yeah, I can. But the location is permanent... but I'll still do just in case. |
| 22:03 | <annevk> | egn, ^^ |
| 22:03 | <AryehGregor> | Is the procedure for getting canconfirm or editbugs on Mozilla's Bugzilla still to e-mail Gerv? |
| 22:03 | <jwalden> | AryehGregor: that's one method; you thinking of asking? |
| 22:04 | <AryehGregor> | jwalden, yes. I seem to meet the requirements at <http://www.gerv.net/hacking/before-you-mail-gerv.html>; for at least canconfirm. |
| 22:04 | <AryehGregor> | Bugs I've filed: https://bugzilla.mozilla.org/buglist.cgi?emailreporter1=1&emailtype1=exact&email1=Simetrical%2Bff⊙gc |
| 22:04 | <jwalden> | AryehGregor: bugmail address? |
| 22:04 | <jwalden> | ah |
| 22:04 | <AryehGregor> | Simetrical+ff⊙gc |
| 22:04 | <AryehGregor> | I have one patch that's r+ and awaiting super-review, and a few other bugs with test-cases (mostly inline as data URLs). |
| 22:05 | <jwalden> | AryehGregor: fixed; bugzilla's administrative permissions are sufficiently fine-grained that there are probably at least a dozen or so people with ability to grant those |
| 22:05 | <AryehGregor> | jwalden, thanks. |
| 22:05 | <egn> | annevk: k, it's not autobuffering, but I need to be able to stop buffering after a play() happens. I think when I pause() it continues to buffer |
| 22:05 | <jwalden> | no problem |
| 22:05 | <AryehGregor> | MediaWiki just gives everyone editbugs, because we're crazy. \o/ |
| 22:06 | <AryehGregor> | (Bugzilla actually works pretty well for that, surprisingly. Not much software does. It keeps good logs and nothing much is irreversible.) |
| 22:06 | <roc> | given that we've had to remove editbugs from people from time to time, that wouldn't work for us |
| 22:06 | <jwalden> | egn: buffering is really a quality-of-implementation issue for the client, except for the hinting mechanism (which may, but probably should not, be ignored) |
| 22:06 | <AryehGregor> | At that stage we usually just disable their account. :) |
| 22:06 | <AryehGregor> | Anyway, just a random comment. |
| 22:06 | <Dashiva> | AryehGregor: And if they create a new one? |
| 22:06 | <roc> | that's a good point |
| 22:06 | <roc> | Dashiva: that tends to not happen |
| 22:06 | <AryehGregor> | Dashiva, same as if they create a new wiki account. |
| 22:06 | <roc> | for some reason |
| 22:07 | <AryehGregor> | I mean, if they want to be disruptive they could also create a new account and write a script to file a constant stream of bugs with goatse hidden in them. Or even do it by hand. |
| 22:07 | <roc> | the exact limits of craziness and malice on the Internet are hard to understand |
| 22:07 | <AryehGregor> | Anyway, it's worked for us so far, although of course we have a much less active Bugzilla than Mozilla does. |
| 22:08 | jwalden | wonders what gnome's bugzilla does, given that it might be the largest out there publicly these days |
| 22:12 | <egn> | jwalden: hm, k. is there any way I can just kill the media element which would stop the buffering after a play()? |
| 22:13 | <jwalden> | egn: not in a cross-browser manner, although disconnecting it from the DOM, making sure it's paused, and then nulling out any and all names and properties that refer to it will likely expedite the process |
| 22:14 | <jwalden> | garbage collection is perhaps the primary non-deterministic behavior on the web that will never be standardized |
| 22:14 | <Philip`> | egn: You could open lots of popup windows so the user gets annoyed enough to terminate their browser process |
| 22:15 | jwalden | snickers |
| 22:15 | <egn> | jwalden: k, thanks |
| 22:19 | <roc> | egn: if you remove the element from the DOM, it will automatically pause and IIRC we'll stop the download |
| 23:08 | <egn> | roc: thanks |
| 23:32 | <egn> | roc: I created the element with document.createElement("audio"); can I still remove that from the DOM? I tried fooAudioElement.remove() with no luck (using jquery) |
| 23:32 | <roc> | did you put it in the DOM? |
| 23:33 | <egn> | I don't think so, I just created it, set the src, and play()ed it |
| 23:33 | <roc> | ah |
| 23:33 | <roc> | hmm |
| 23:34 | <roc> | ok, stopping it from downloading is kinda hard |
| 23:34 | <roc> | you can drop all references to it and wait for GC to kill it, but that's unknown delay |
| 23:34 | <egn> | ok. should I just put an empty <audio> element on page load and then just change it's src and such? |
| 23:35 | <roc> | you could insert it into an inactive document so that its owner document is an inactive document, which will stop the download, but that's rather obscure |
| 23:35 | <egn> | k |
| 23:35 | <roc> | what are you actually trying to do |
| 23:35 | <egn> | change songs |
| 23:36 | <roc> | can't you just change the .src and call load()? |
| 23:36 | <egn> | so once a song changes, I don't want it to buffer the old one |
| 23:36 | <egn> | I'll try that |
| 23:41 | <egn> | works, thanks |