| 01:09 | <llrcombs> | Can't anyone just tell me "sounds good, we might add it" or "that's a crappy idea, and here's why"? |
| 01:09 | <llrcombs> | Idea: Methods in <track> to programatically add/remove/edit cues |
| 01:10 | <AryehGregor> | I'm pretty sure most people here aren't following the <track> stuff. |
| 01:10 | <AryehGregor> | Thus the lackluster response. |
| 01:10 | <llrcombs> | is there another chan I should ask in? |
| 01:24 | <zewt> | post on the list |
| 01:25 | <llrcombs> | how about the forums? |
| 01:25 | <zewt> | what forums? heh |
| 01:26 | <llrcombs> | the whatwg forums |
| 01:26 | <llrcombs> | forums.whatwg.org |
| 01:27 | <zewt> | don't know about those, development doesn't happen on forums |
| 01:27 | <llrcombs> | http://forums.whatwg.org/bb3/viewforum.php?f=3 |
| 01:27 | <zewt> | don't know what that even exists, stick to the list |
| 01:28 | <llrcombs> | link? |
| 01:28 | <llrcombs> | (I like forums D:) |
| 01:28 | <zewt> | https://encrypted.google.com/search?q=whatwg+mailing+list |
| 01:29 | <llrcombs> | yay encrypted google |
| 01:29 | <llrcombs> | yeah, that was probably a stupid question |
| 06:37 | <zcorpan> | input from webkit people on http://www.w3.org/Bugs/Public/show_bug.cgi?id=12798 would be nice |
| 07:00 | <heycam> | zcorpan, I agree, thanks for ccing abarth |
| 07:01 | <heycam> | (although I'm loathe to reopen without some concrete data) |
| 07:01 | heycam | heads home |
| 07:25 | <MikeSmith> | Ben Meyer is stopping work on Arora - http://groups.google.com/group/arora-dev/browse_thread/thread/c3c318b78a655039 |
| 07:26 | <MikeSmith> | I guess it was inevitable |
| 07:56 | <hsivonen> | MikeSmith: is George Staikos still at Torch/RIM? is he prohibited from doing Qt stuff as well? |
| 07:57 | <MikeSmith> | hsivonen: not sure if George is at RIM or not |
| 07:57 | <MikeSmith> | but yeah it would really suck if he weren't allowed to work on Qt stuff |
| 08:03 | <MikeSmith> | hsivonen: looking through http://trac.webkit.org/browser/trunk/Source/WebKit/qt it seems like it's been a long time since he committed any changes himself against the sources for the Qt port of WebKit |
| 08:05 | <hsivonen> | MikeSmith: ok |
| 08:07 | <MikeSmith> | so hsivonen , about the input-type error message thing, when you mentioned punching holes in some abstractions, did you mean in the validator.nu branch of jing? |
| 08:08 | <MikeSmith> | because as far as what's currently available to the message-emitter code, that would seem like the only place to do it |
| 08:10 | <hsivonen> | MikeSmith: I haven't looked at the code, but AFAICT, there are two options: 1) Making Jing expose the attributes in the exception and 2) Making the message emitter register a SAX ContentHandler that gets served earlier than Jing so that the message emitter knows which SAX event Jing is about to get |
| 08:10 | <MikeSmith> | ah |
| 08:10 | <MikeSmith> | OK |
| 08:11 | <MikeSmith> | I see |
| 08:12 | <MikeSmith> | I reckon registering a new content handler might be easier than making the changes to Jing |
| 08:12 | <MikeSmith> | maybe not technically easier |
| 08:12 | <hsivonen> | I'd expect it to be the better route |
| 08:12 | <hsivonen> | especially if we try to pursue merging with Jing trunk some day |
| 08:13 | <MikeSmith> | right |
| 08:13 | <MikeSmith> | it seems like James would rather not see further changes going into the validator.nu branch that he doesn't want in the trunk |
| 08:14 | <MikeSmith> | and getting his review time & attention is also not very easy |
| 08:14 | <hsivonen> | hmm. http://help.yandex.ru/webmaster/?id=995300#995356 doesn't look like a great "spec" for yandex-verification |
| 08:15 | <hsivonen> | since the page doesn't even mention what the meta keyword is |
| 08:19 | <hsivonen> | Hixie: any advice about yandex-verification? |
| 08:19 | <othermaciej> | George Staikos is at RIM, yes |
| 08:19 | <othermaciej> | I think their port might be based on Qt, but I am not sure |
| 08:20 | <hsivonen> | Hixie: it seems totally silly to fail yandex-verification for failing the requirements, but not failing it would set an awful precedent |
| 08:21 | <hsivonen> | fwiw, the English version of the doc at http://help.yandex.com/webmaster/?id=1115204 doesn't mention the actual meta keyword, either |
| 08:26 | <MikeSmith> | so I did some hacking on the bugzilla mail code to try to get notifications in which the record of changes is easier to read than the default bugzilla ascii-table thing |
| 08:26 | <hsivonen> | Hixie: oh well, I moved the entry to the list of keywords that don't meet the requirements, since, objectively, it doesn't :-( |
| 08:26 | <MikeSmith> | result so far is here: |
| 08:27 | <MikeSmith> | https://raw.github.com/gist/1035260/5ba6711823a527ba670ad06f1289599426cba6c4/gistfile1.txt |
| 08:27 | <MikeSmith> | opinions on that would be welcome |
| 08:27 | <MikeSmith> | and/or suggestions for further tweaks |
| 08:27 | <hsivonen> | MikeSmith: WFM |
| 08:27 | <MikeSmith> | ok |
| 08:28 | <MikeSmith> | unfortunately the bugzilla template mechanism doesn't provide any way to adjust the formatting of that part of the notifications |
| 08:28 | <MikeSmith> | the ascii-table part |
| 08:28 | <MikeSmith> | so changing it requires hacking the system BugMail.pm file |
| 08:29 | <MikeSmith> | which means if we deploy this for the W3C bugzilla, I will need to the W3C systems team to agree to it |
| 08:29 | <MikeSmith> | so I hope I can do that |
| 08:30 | <MikeSmith> | but I really think this should be changed in bugzilla upstream |
| 08:30 | <MikeSmith> | that ascii-table stuff only displays well in fixed-width font anyway |
| 08:30 | <zewt> | heh |
| 08:30 | <zewt> | mails formatted as if everyone reads mail in a terminal in 2011 is sort of uhh |
| 08:31 | <MikeSmith> | and I reckon a quite large number or users these days are reading those messages in a client that displays them using a proportional font |
| 08:31 | <MikeSmith> | e.g., Gmail or Mail.app or Outlook or whatever |
| 08:32 | <MikeSmith> | zewt: well, I guess a lot of bugzilla users still do read mail in clients with fixed-width fonts |
| 08:32 | <MikeSmith> | at least I do still |
| 08:32 | <MikeSmith> | most of the time |
| 08:33 | MikeSmith | wonders if there's a way to have gmail use a fixed-width font |
| 08:35 | MikeSmith | checks and sees it seems not (other than changing browser settings) |
| 08:36 | <MikeSmith> | seems that iPad mail client doesn't provide any way to change the font-family either |
| 08:36 | <hsivonen> | yay IETF. the about: URL scheme has existed since early Netscape and now we get feedback that the W3C shouldn't use it while the IETF ponders it |
| 08:36 | <zcorpan> | about:ietf |
| 08:39 | <zewt> | MikeSmith: you can send an HTML version set to a fixed-width font, but ... please don't, heh |
| 08:39 | <zewt> | the only legitimate case I've seen for changing fonts in mail so far is when pasting code into a mail; setting fixed-width is sort of useful then |
| 08:40 | <MikeSmith> | about:clue |
| 08:41 | <MikeSmith> | zewt: I think fixed-width font for e-mail is pretty much better for readability regardless |
| 08:42 | <MikeSmith> | I don't know of many use cases for really needing typography fineries in e-mail |
| 08:42 | <MikeSmith> | e-mail messages are word-processing docs |
| 08:42 | <MikeSmith> | or web pages |
| 08:43 | <zewt> | fixed-width is pretty bad for readability in general, but of course that's the reader's choice, not the sender's :) |
| 08:47 | <asmodai> | Mmm |
| 08:48 | <asmodai> | hsivonen: I wonder why the firefox 5 installer doesn't invoke UAC to allow me to install |
| 08:48 | <zewt> | heh |
| 08:48 | <asmodai> | Trying to install it complains about not having rights to write to the destination directory. Have to right click and run as administrator |
| 08:48 | <zewt> | clicking chrome install links in firefox and having it go "done!" is pretty much "uhhh, what?" |
| 08:48 | <asmodai> | zewt: heh |
| 08:49 | <hsivonen> | zewt: do you mean after installing some other app from Google that installs an NPAPI plug-in into Firefox without asking? |
| 08:49 | <zewt> | i have no idea what it was, actually |
| 08:49 | <hsivonen> | asmodai: I have no idea. I know very little about Windows |
| 08:50 | <zewt> | maybe it was the "upgrade chrome to testing" or whatever |
| 08:50 | <asmodai> | hsivonen: Just curious, since previous versions requested those permissions. |
| 08:50 | <hsivonen> | zewt: AFAICT, Opera is the only major competing browser vendor that doesn't try to inject code into Firefox under any circumstances |
| 08:51 | <hsivonen> | kudos to Opera |
| 08:51 | <zewt> | Google Update 1.3.21.57 |
| 08:51 | <zewt> | yeah google installed some plugin into firefox without permission |
| 08:54 | <hsivonen> | Firefox really needs to start prompting the user with something like "Hey, $VENDOR added some code into Firefox without asking you. [Cool, Let's Run More Code] [[Not Cool, Reject the Code]]" |
| 08:55 | <zewt> | also google needs to stop installing things without permission because that's not "okay" |
| 08:57 | <hsivonen> | as I understand it, the stuff Google installs is less of a problem than stuff antivirus packages or Skype install |
| 08:57 | <zewt> | heh i use a skype from like 2008 because anything newer is unusable |
| 08:59 | <zewt> | surprised it even works |
| 08:59 | <othermaciej> | which browser vendors inject code into Firefox and how? |
| 08:59 | <zewt> | chrome appears to install a plugin into firefox |
| 09:00 | <othermaciej> | does the way they do it obtain meaningful user consent? |
| 09:00 | <zewt> | none that I can recall giving |
| 09:00 | <othermaciej> | if it wasn't a Google product that would probably be considered malware |
| 09:00 | <zewt> | i consider it malware anyway :) |
| 09:01 | <zewt> | malware I'm marginally less worried about exploding my system, but nonetheless |
| 09:01 | <hsivonen> | othermaciej: Google installs the above-mentioned Google Update plug-in when you install Chrome. Apple installs the QuickTime Plug-in if you install a fully-functional version of Safari (QuickTime is required for fully-functional Safari), if you install something that requires Microsoft Genuine Advantage Validation, you end up with a Microsoft plug-in in Firefox while doing something that isn't obviously about installing stuff into Firefox |
| 09:02 | <hsivonen> | othermaciej: I think the Google Update plug-in doesn't involve meaningful consent |
| 09:03 | <othermaciej> | The QuickTime plugin is mainly bundled for Safari's actual use |
| 09:03 | <othermaciej> | though I suppose we could go out of our way to keep other browsers from finding it, but that would be weird |
| 09:03 | <othermaciej> | Apple's not really pushing QuickTime plugin as a way to deliver video so who knows what will happen in the future |
| 09:03 | <hsivonen> | othermaciej: to make <video> work in Safari, you need to install QuickTime. And as a side effect, Apple puts code into other browsers on the system, too |
| 09:04 | <othermaciej> | making <video> work in Safari for Windows is bundled with making QuickTime plugin content work in Safari for Windows |
| 09:04 | <othermaciej> | which also happens to make it work in other browsers |
| 09:05 | <othermaciej> | (on Mac of course all three of Safari, Safari's ability to play <video> content, and the QuickTime plugin, are bundled with the OS) |
| 09:06 | <hsivonen> | othermaciej: aren't there two QuickTime plug-ins on Mac? |
| 09:06 | <hsivonen> | othermaciej: one for Safari and another for other browsers? |
| 09:06 | <abarth> | hsivonen: what's the name of the plugin that chrome installs? |
| 09:06 | <abarth> | Google Update ? |
| 09:07 | <othermaciej> | hsivonen: there used to be, but that is no longer true |
| 09:07 | <zewt> | yeah that's what's in my FF install |
| 09:07 | <zewt> | (which I assume is from Chrome; the only other Google stuff I have installed is Android dev tools) |
| 09:07 | <hsivonen> | abarth: that's what zewt said above. I don't have a Windows VM running to confirm the name right now, but I've seen it myself, too |
| 09:07 | <othermaciej> | we are de-emphasizing WebKit-specific plugins and in fact they no longer work in Safari 5.1 |
| 09:07 | <othermaciej> | since there was no sane way to make them work with multiprocess |
| 09:07 | <abarth> | ah, the pack thing |
| 09:07 | <abarth> | http://www.google.com/support/pack/bin/answer.py?answer=30252 |
| 09:08 | <hsivonen> | abarth: I got it without ever trying to install a "Pack" |
| 09:08 | <othermaciej> | at least since SnowLeopard there has been only one QuickTime plug-in |
| 09:08 | <hsivonen> | othermaciej: oh. ok |
| 09:09 | <hsivonen> | so Safari 5.1 will break Click-to-Flash? |
| 09:10 | <abarth> | hsivonen: this the problem with arbitrary code |
| 09:10 | <abarth> | hsivonen: its hard to stop people from dumping junk in places it doesn't belong |
| 09:10 | <othermaciej> | it won't break the Click-to-Flash Safari extension |
| 09:10 | <othermaciej> | I don't know if the plugin-based version is still active |
| 09:11 | <hsivonen> | I was unaware that Click-to-Flash had migrated into an extension |
| 09:12 | <abarth> | i wonder if there's some pseudo technical solution whereby you require some kind of on-disk assertion claim that the user actively consented to the install |
| 09:12 | <othermaciej> | the plugin-based version looks like it hasn't been touched in a year or two and there is indeed an extension, though not by the same person |
| 09:12 | <abarth> | and then people who forged that would look silly and get bad PR |
| 09:13 | <othermaciej> | the only way to really solve this problem is to limit software installs to a curated walled garden, and sandbox the hell out of everything |
| 09:13 | <abarth> | :) |
| 09:13 | <othermaciej> | not to say there aren't arguable downsides to that approach |
| 09:13 | <othermaciej> | but seriously |
| 09:13 | <zewt> | it's discouraging that Google is setting such a bad example, though, which makes everyone else go "Google does it, so it's okay!" |
| 09:14 | <abarth> | yep :( |
| 09:15 | <othermaciej> | I wonder if it is on purpose or a side effect |
| 09:15 | <othermaciej> | when Microsoft products install an plugin picked up by Firefox, that's clearly not just a side effect of doing it for IE |
| 09:16 | <abarth> | i suspect the plugin is useful for pack |
| 09:16 | <abarth> | i don't know whether the install is intentional for non-pack installs |
| 09:16 | <abarth> | its the thing that manages which pieces of pack you've got installed |
| 09:19 | <hsivonen> | Google Update seems to enable special powers on google.com. Is there any way to find out how well in locks itself to google.com to prevent random sites from exercising the special powers? |
| 09:19 | <hsivonen> | likewise for Genuine Advantage Validation |
| 09:20 | <hsivonen> | it's also about giving special powers to Microsoft sites and isn't meant to be used by random third parties |
| 09:20 | <abarth> | hsivonen: there's no good way in NPAPI to figure out what site you're on |
| 09:20 | <abarth> | so folks copy the hack that Flash uses |
| 09:20 | <hsivonen> | in principle, the QuickTime plug-in is general purpose, but in practice, it too is in practice used for apple.com only these days :-) |
| 09:21 | <abarth> | if you don't copy the hack precisely correctly, you run into security trouble |
| 09:21 | <othermaciej> | is Google Update limit itself to SSL google.com? |
| 09:21 | <hsivonen> | s/in practice// |
| 09:21 | <abarth> | one hopes! |
| 09:21 | <abarth> | even then there are problems |
| 09:21 | <abarth> | if you assume users click through certificate errors |
| 09:21 | <hsivonen> | abarth: what's the hack? |
| 09:21 | <abarth> | i suspect it verifies the signature on binaries |
| 09:21 | <othermaciej> | I don't think apple.com uses the QuickTime plug-in much |
| 09:22 | <abarth> | since that's how omaha works |
| 09:22 | <othermaciej> | almost all video content I know of on apple.com is <video> |
| 09:22 | <hsivonen> | othermaciej: for Safari, yes |
| 09:22 | <abarth> | hsivonen: using a JavaScript URL to read the value of window.location.href |
| 09:22 | <hsivonen> | othermaciej: for other browsers, no |
| 09:22 | <hsivonen> | abarth: scary |
| 09:22 | <abarth> | yes, it doesn't actually work |
| 09:22 | <abarth> | except that we've made it work by brute force |
| 09:23 | <abarth> | we need a real NPAPI for getting this information |
| 09:23 | <abarth> | Peleus is supposed to propose something on plugin-futures |
| 09:24 | <abarth> | but I think he's been buried recently with flash security issues |
| 09:24 | <hsivonen> | if Apple.com was a normal H.264 site, it would use Flash Player instead of QuickTime Plug-in :-) |
| 09:41 | <asmodai> | *groan* http://arstechnica.com/apple/news/2011/06/ny-post-blocks-access-to-its-website-on-ipads-to-drive-app-purchases.ars |
| 09:48 | <hsivonen> | asmodai: that's not good. rumor has it that similar things have happened on Android, too |
| 09:48 | <hsivonen> | why aren't they doing the same to Windows? |
| 09:48 | <hsivonen> | (yes, I know there's no App Store on Windows) |
| 09:49 | <laxminarayan> | hi .. was readign the first paragraph, and was wondering why HTML (or any other) spec version numbers cant be like version numbers of many open source softwares? Odd ones unstable, and even ones stable |
| 09:49 | <laxminarayan> | http://diveintohtml5.org/past.html |
| 09:56 | <hsivonen> | laxminarayan: stable releases of specs are obsolete upon publication |
| 09:58 | <MikeSmith> | so if ICANN creates, say, a .js TLD, who gets to own that TLD? |
| 09:59 | <MikeSmith> | or .app |
| 09:59 | <MikeSmith> | or whatever else |
| 09:59 | <zcorpan> | i guess pubsuffix will need to list TLDs now as well |
| 10:00 | <zcorpan> | uh, or maybe not |
| 10:00 | <jgraham> | MikeSmith: You do |
| 10:00 | <jgraham> | We asked ICANN specially |
| 10:00 | <hsivonen> | MikeSmith: I'd expect the ownership to be about money. Why else would they create more TLDs? |
| 10:01 | <jgraham> | And they said, "yeah he's that guy, isn't he? Sure thing!" |
| 10:01 | <MikeSmith> | eh |
| 10:01 | <MikeSmith> | heh |
| 10:01 | <asmodai> | hsivonen: the open web is really threated by such moves :( |
| 10:02 | <MikeSmith> | jgraham: as long as the cash goes in my pocket instead of the other way around |
| 10:02 | <MikeSmith> | hsivonen: yeah, around $185,000 USD apparently |
| 10:02 | <asmodai> | I wonder how this tradename TLD stuff will work out in the end. I mean, all fun to have .apple and be able to do http://apple/ or http://store.apple/ - kind of reminds of keywords in the CompuServe days |
| 10:02 | <asmodai> | MikeSmith: And EUR 17000 a year |
| 10:02 | <asmodai> | so, USD 19000 or so? |
| 10:02 | <MikeSmith> | geez |
| 10:03 | <zcorpan> | app.store |
| 10:03 | <asmodai> | zcorpan: Heh |
| 10:03 | <MikeSmith> | Joyent seems to like Javascript, and has money |
| 10:03 | <asmodai> | zcorpan: I can see the lawsuits starting. |
| 10:03 | <jgraham> | I'm surprised they're not doing it by auction |
| 10:04 | <hsivonen> | who gets to pocket the $185K? |
| 10:04 | <zcorpan> | is there a length limit on TLDs? |
| 10:04 | <jgraham> | Presumably .sex and .apple will be more valuable than .quuz |
| 10:05 | <MikeSmith_> | hsivonen: dunno who gets the money. I guess I assumed it went to ICAAN |
| 10:05 | <MikeSmith_> | or ISOC |
| 10:07 | <hsivonen> | does ISOC like gratuitous TLDs now? |
| 10:07 | <zcorpan> | who gets the money? |
| 10:07 | <zcorpan> | every dollar of it. |
| 10:07 | <asmodai> | first they're bitching for years about xxx |
| 10:07 | <MikeSmith_> | I guess ISOC probably likes it better if they are the ones getting money for it instead of somebody else |
| 10:08 | <MikeSmith> | asmodai: I guess once the went xxx they had to go full-absurd and permit whatever else |
| 10:10 | <asmodai> | heh |
| 10:11 | <zcorpan> | interesting that there were 16 people who voted about this change |
| 10:11 | <hsivonen> | why do email apps have to suck this much |
| 10:12 | <foolip> | zcorpan, yes, we'd fire canplaythrough again for example if you play through to the end and then seek back to the middle |
| 10:12 | <zcorpan> | foolip: ok. then we're compliant :) |
| 10:16 | <zcorpan> | <http://www.w3.org/mid/E6F26D0D-5F1D-4E4F-9793-DC93D4EBCFF5⊙nc>; - yes, let's have flamewars about who can and can't be Editorial Assistants |
| 10:19 | <asmodai> | So I decided to use Google's HTML5 video support yesterday. Not entirely sure if I like the current lack of full screen mode. Sucks when using 2+ monitors to watch livestreams on 1, you lose some screen estate due to the browser window. |
| 10:19 | <asmodai> | I understand the security concerns though. |
| 10:25 | <othermaciej> | there is no real security issue with video fullscreen |
| 10:25 | <nessy> | it's in the process of getting implemented FAIK |
| 10:26 | <othermaciej> | YouTube uses full-window in HTML5 mode instead of fullscreen because they want custom controls |
| 10:26 | <othermaciej> | Safari 5.1 enables fullscreen video with custom controls so hopefully they will adopt that (I think Vimeo already has) |
| 10:30 | <asmodai> | That's odd, when I searched on this the reason cited was security concerns with full screen ads taking over in a programmatic way. |
| 10:32 | <asmodai> | http://stackoverflow.com/questions/1055214/is-there-a-way-to-make-html5-video-fullscreen |
| 10:33 | <jgraham> | zcorpan: Would make a nice change from flamewars about who should be allowed to have an opinion in flamewars about accessibility |
| 10:34 | <asmodai> | rofl |
| 10:47 | <zewt> | othermaciej: well, hopefully nobody will adopt a fullscreen api that's *specific* to video... |
| 10:48 | <othermaciej> | Safari used to have one that was specific to video, we are now adding one that is generic to any element |
| 10:48 | <zewt> | (that would just delay a real API) |
| 10:48 | <othermaciej> | (in the just-released Safari developer preview) |
| 10:48 | <zewt> | (i'm always nervous at deployed half-measures, for that reason) |
| 10:50 | <hsivonen> | othermaciej: what mechanism will Safari 5.1 use for enabling custom controls for full screen video? |
| 10:50 | <othermaciej> | hsivonen: our implementation of the Mozilla-proposed fullscreen API |
| 10:51 | <othermaciej> | which really should be turned into a real spec and maybe I'll try to get someone at Apple to do that |
| 10:51 | <othermaciej> | we found many issues with the original design while implementing, some not yet fixed in our implementation |
| 10:51 | <othermaciej> | we are shipping it webkit-prefixed |
| 10:51 | <hsivonen> | othermaciej: it's nice that you went with roc's proposal |
| 10:52 | <hsivonen> | thanks |
| 10:52 | <othermaciej> | MikeSmith: is it written down anywhere that Chairs appoint editors? |
| 10:52 | <othermaciej> | hsivonen: well, there's a lot of stuff that needs to be fixed in it but we ran out of time |
| 10:52 | <othermaciej> | fortunately what we shipped is prefixed |
| 10:52 | <MikeSmith> | othermaciej: dunno, will take a look |
| 10:52 | <othermaciej> | however I doubt we will be able to stop video sites from using it |
| 10:53 | <othermaciej> | MikeSmith: I couldn't find anything to that effect (or indeed any mention of editors) in the W3C Process Document |
| 10:53 | <othermaciej> | ah, found it |
| 10:53 | <othermaciej> | "Every technical report published as part of the technical report development process is edited by one or more editors appointed by a Working Group Chair. " |
| 10:53 | <MikeSmith> | ok |
| 10:55 | <MikeSmith> | so it seems pretty clear the editorial appointments are at the discretion of the chairs |
| 10:55 | <MikeSmith> | if you want, I can talk to plh about this |
| 10:56 | <othermaciej> | no need |
| 10:56 | <MikeSmith> | and if he agrees and you think it'd help, I can ask him to post a message to the thread on public-html confirming that |
| 10:56 | <MikeSmith> | OK |
| 10:57 | <othermaciej> | I was just looking for a cite for Mark Watson, and I couldn't find one at first, which made me wonder if this wasn't written down anywhere |
| 10:57 | <MikeSmith> | I would post a message myself confirming it, but that I don't think that would carry a whole lot of weight in this group |
| 10:57 | <MikeSmith> | OK |
| 10:57 | <MikeSmith> | I hope that will satisfy Mark's question |
| 11:03 | <MikeSmith> | hmm, gerv is listed as one of the owners of the BugMail.pm code |
| 11:04 | <MikeSmith> | I wonder if he actually still has time to work on it actively at all |
| 11:04 | <MikeSmith> | would be nice to get his feedback about how to improve the plain-text output to remove that ascii-table-layout stuff |
| 11:15 | <annevk> | hmm |
| 11:15 | <annevk> | will have to see if I get to a WHATWG Weekly today |
| 11:16 | <annevk> | if I do it will likely be vastly incomplete, but I guess that is unavoidable anyway |
| 11:22 | <annevk> | Inbox 1337 |
| 11:33 | <annevk> | a shit |
| 11:33 | <annevk> | CORS is moving into some other WG |
| 11:33 | <annevk> | http://www.w3.org/2010/07/appsecwg-charter |
| 11:33 | <annevk> | I guess I knew that already |
| 11:35 | <hsivonen> | hmm. isn't moving security to a different group like putting a11y or i18n in a dedicated group? |
| 11:35 | <hsivonen> | whoa. is UMP still alive? |
| 11:41 | <annevk> | hsivonen, it does not strike me as a good idea |
| 11:41 | <annevk> | hsivonen, I think at some point Hixie and I might end up merging "fetch" and CORS |
| 11:49 | <hsivonen> | is there a spec that says what createDocument().readyState must return? |
| 11:49 | <annevk> | HTML5 should define that |
| 11:50 | <othermaciej> | "Deliverables under this work item will be published as joint deliverables with the Web Applications Working Group." |
| 11:51 | <othermaciej> | not sure what the value of that is |
| 11:51 | <othermaciej> | not to mention it seems this would require an update of the Web Apps charter |
| 11:51 | <hsivonen> | othermaciej: at least RDFa being done as a joint venture between the XHTML2 WG and a SemWeb group was considered to be of value |
| 11:52 | <othermaciej> | hsivonen: are you trolling me? |
| 11:52 | <hsivonen> | othermaciej: whenever someone says RDFa was done by the XHTML2 WG, there's someone else reminding that it was a joint venture |
| 11:52 | <othermaciej> | (I can't tell) |
| 11:52 | <hsivonen> | othermaciej: I'm not. just making an observation about the previous joint venture I'm aware of |
| 12:01 | <MikeSmith> | annevk: now that the Web Notifications WG chair is back, I think he should please do some lobbying to get Notifications support into more browser engines |
| 12:02 | <MikeSmith> | e.g., Opera for one |
| 12:02 | <MikeSmith> | http://caniuse.com/#search=notifications don't look so nice |
| 12:03 | <annevk> | hsivonen, it should return "complete" per HTML5 |
| 12:04 | <smaug____> | MikeSmith: I should kick dougt to implement those in Fx. |
| 12:04 | <hsivonen> | annevk: but why? |
| 12:04 | <hsivonen> | annevk: readyState is an IE API originally and IE says uninitialized |
| 12:05 | <smaug____> | MikeSmith: did the other notification API disappear. The not-so-good which allowed url loading? |
| 12:05 | <annevk> | hsivonen, I'm just telling you what the spec says |
| 12:05 | <hsivonen> | annevk: ok |
| 12:05 | <MikeSmith> | smaug____: yes, please do get dougt attention on it |
| 12:05 | <smaug____> | ah, it is still here http://dev.w3.org/2006/webapi/WebNotifications/publish/WebNotifications.html |
| 12:05 | <MikeSmith> | yeah |
| 12:05 | <annevk> | hsivonen, it does make more sense to me than uninitialized though if this is about loading primarily |
| 12:05 | <annevk> | hsivonen, well, readyness |
| 12:05 | <hsivonen> | annevk: see topic |
| 12:05 | <smaug____> | MikeSmith: I assume you mean http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html |
| 12:06 | <smaug____> | MikeSmith: I mean, you want that to be implemented |
| 12:06 | <MikeSmith> | smaug____: yep |
| 12:06 | hsivonen | is unhappy about stuff like this arbitrarily getting made logical |
| 12:06 | <MikeSmith> | smaug____: Chrome's the only app so far that supports any of it |
| 12:06 | <smaug____> | Mobile Fx should have some support |
| 12:06 | <MikeSmith> | and it does support the URL part |
| 12:07 | <MikeSmith> | ok |
| 12:07 | jgraham | is not very happy about the URL part |
| 12:07 | <MikeSmith> | I'm curious how this will end up being implemented on mobile platforms |
| 12:08 | <jgraham> | I think text-only notifications are the right first step |
| 12:08 | <smaug____> | I agree |
| 12:08 | <MikeSmith> | I don't know what kind of useful notification mechanisms most mobile OSes/platforms have these days |
| 12:08 | <MikeSmith> | I can't remember who it was that was keen on the URL part |
| 12:08 | <MikeSmith> | maybe it was just the editor :) |
| 12:08 | <jgraham> | |
| 12:09 | <MikeSmith> | I think there are some even on the Chrome team that weren't so keen on it |
| 12:09 | <jgraham> | Well yes, I don't expect total internal harmony |
| 12:09 | <jgraham> | On anything really |
| 12:10 | <MikeSmith> | in other news, I'm wondering if caniuse.com exposes any kind of API that would be useful for integration into other sites |
| 12:10 | <MikeSmith> | e.g., we could use it annotate the spec with stability annotations |
| 12:10 | <annevk> | I believe WebOS has something like it |
| 12:10 | <smaug____> | MikeSmith: does Chrome implement notification API using webkit or chrome prefix? |
| 12:11 | <hsivonen> | the URL-based notification stuff was a done deal for Chrome, so of course it's part of HTML5 and the Web |
| 12:11 | <MikeSmith> | smaug____: webkit-* I think |
| 12:11 | <MikeSmith> | hsivonen: maybe the chair should put some thought into that |
| 12:12 | hsivonen | is still grumpy about how Chrome Notifications were announced as HTML5 Notifications |
| 12:12 | <MikeSmith> | well, we have a real spec for it now |
| 12:12 | <MikeSmith> | so that's all water under the bridge |
| 12:13 | <MikeSmith> | along with a lot of other such water |
| 12:13 | jgraham | is still grumpy |
| 12:13 | <MikeSmith> | waiting to resurface and drown us all eventually |
| 12:13 | <jgraham> | Just in general |
| 12:13 | <MikeSmith> | i'm mostly just trying to give annevk a hard time |
| 12:13 | <smaug____> | hsivonen: Google did the same with HTML Speech. "Chrome implements HTML5 Speech API" (although there isn't such thing) |
| 12:14 | <hsivonen> | smaug____: yeah, that, too |
| 12:14 | <jgraham> | MikeSmith: Since he has been buming around for months, he deserves it :) |
| 12:14 | <hsivonen> | maybe Mozilla should have branded the Firefox Audio API as the HTML5 Audio API |
| 12:15 | <MikeSmith> | the world seems more right now that annevk is back at work |
| 12:16 | <annevk> | feels kind of odd still to be back at work |
| 12:16 | MikeSmith | joins #bugzilla on irc.mozilla.org in anticipation of hoping to get some a11y changes made upstream |
| 12:16 | <smaug____> | annevk: hope you had a great vacation |
| 12:16 | <jgraham> | You anticipate hoping to get them made? Do you also anticipate getting them made? |
| 12:17 | <jgraham> | :) |
| 12:17 | <MikeSmith> | jgraham: yes (to one of those questions) |
| 12:31 | <MikeSmith> | great |
| 12:32 | <MikeSmith> | so glob just marked my bugzilla enhancement request as a simple duplicate of another bug |
| 12:32 | <annevk> | http://www.contextis.com/resources/blog/webgl2/ |
| 12:32 | <MikeSmith> | except that bug actually has nothing at all to do with the request I'm making |
| 12:32 | <MikeSmith> | annevk: yeah :( |
| 12:33 | <MikeSmith> | hopefully we can get those problems fixed |
| 12:34 | <MikeSmith> | annevk: but as you may have seen (or will see as you get through e-mail backlog), the problems described there are not necessarily unique to WebGL |
| 12:34 | <MikeSmith> | but general problems that any API that reaches down into graphics-cards innards is going to run into |
| 12:34 | <MikeSmith> | or has already run into and not actually fixed yet either |
| 12:35 | <hsivonen> | annevk: https://twitter.com/#!/m_bitsnbites/status/82716250001772544 |
| 12:36 | <MikeSmith> | jesus, are there actually a lot of programs that are hard-coded to parse that table-layout stuff in bugzilla e-mail notifications |
| 12:37 | <MikeSmith> | if so, well, what a sad state of affairs that is |
| 12:37 | <heycam> | MikeSmith, maybe you can make it send an text/html part? |
| 12:37 | <MikeSmith> | heycam: that is actually what bugzilla 4.2 is going to do |
| 12:37 | <MikeSmith> | but that's not a fix |
| 12:38 | <MikeSmith> | it's great to have an alternative |
| 12:38 | <MikeSmith> | but there are plenty of people who still use the plain-text stuff and want it to actually be readable |
| 12:38 | <MikeSmith> | e.g., Janina uses mutt |
| 12:38 | <heycam> | hey, I use mutt |
| 12:38 | <heycam> | :) |
| 12:38 | <MikeSmith> | I do too :) |
| 12:40 | <heycam> | curses-based applications probably aren't great for blind users, admittedly |
| 12:40 | <MikeSmith> | well, Janina seems to be able to work with it pretty well in spite of that |
| 12:41 | <heycam> | interesting |
| 12:41 | <MikeSmith> | and she does for a lot of other stuff too that most people would wonder how a non-sighted user could ever deal with it |
| 12:42 | <MikeSmith> | anyway, it ain't too call to tell Janina she can't get screenreader-readable plain-text notifications from bugzilla because too bad sorry there are so many programs that rely on the parsing the current fecking table-layout formatting that was a misguided idea to begin with |
| 12:42 | <heycam> | yeah, that sucks |
| 12:42 | <heycam> | I wonder, if using a curses-based interfaces, if there is really any better way to aurally presents tables, though |
| 12:43 | <MikeSmith> | point is, there is absolutely no reason why it needs to be presented in a (pseudo) table format anyway |
| 12:43 | <MikeSmith> | it could just be a list |
| 12:43 | <heycam> | oh, true |
| 12:43 | <MikeSmith> | yeah, it's more redundant |
| 12:43 | <MikeSmith> | and less purty |
| 12:44 | <heycam> | (the purtyness is debatable) |
| 12:44 | <MikeSmith> | yeah |
| 12:44 | <MikeSmith> | and anyway, who the fuck cares how purty the bugzilla e-mail notifications they get are |
| 12:45 | <MikeSmith> | I feel the need for a j break coming on |
| 12:45 | <MikeSmith> | calming effects of green tea alone are not powerful enough for this case |
| 12:51 | <annevk> | Hixie, btw, very much in favor of merging HTML and WA 1.0 |
| 12:59 | <hsivonen> | http://lists.w3.org/Archives/Public/public-lod/2011Jun/0082.html |
| 13:03 | <hsivonen> | http://lists.w3.org/Archives/Public/public-lod/2011Jun/0269.html |
| 13:09 | <annevk> | sweet |
| 13:10 | <annevk> | I like that guy |
| 13:10 | <annevk> | he was once at a HTML WG meeting too, very practical and straightforward |
| 13:14 | <asmodai> | annevk: well formulated answer/point |
| 13:14 | <asmodai> | annevk: Working for a university atm I totally recognize the NIH mentality |
| 13:14 | <asmodai> | and the "not looking beyond academic application" part |
| 13:23 | <gsnedders> | annevk: Yeah, he's very awesome. Esp. talking about academia in such terms while being a researcher (at Edinburgh). |
| 13:39 | <annevk> | anyone care to quickly login to the blog and review my draft? |
| 13:40 | <annevk> | gonna publish in a few minutes otherwise |
| 13:44 | <hsivonen> | annevk: looking at your draft |
| 13:45 | <hsivonen> | annevk: looks ok |
| 13:46 | <annevk> | cool, I guess if people point out a bunch of stuff I missed I can do another one on Thursday or so |
| 14:02 | <annevk> | Is anyone going to send in Last Call comments for DOM Level 3 Events? |
| 14:18 | <annevk> | Inbox <1000 |
| 14:22 | <asmodai> | lol, on twitter: ICANN haz .cheezburger? |
| 14:25 | <annevk> | hahaha |
| 14:27 | <annevk> | I raised DOM Level 3 Events issues and never got a personal reply... |
| 16:45 | <karlcow> | https://docs.google.com/present/view?id=dd4bk538_182f55p5x3f |
| 16:46 | <karlcow> | All About EVE Extensibility, Versioning, Evolvabiility, etc. thru Modifiability Mike Amundsen |
| 16:49 | <AryehGregor> | Nice, this Flash form I'm filling out (which would have been dead simple to do in HTML+JS, doesn't use any special Flash features) doesn't support RTL properly. |
| 16:49 | <AryehGregor> | I'd have thought Flash would be less incompetent than that. |
| 16:51 | <AryehGregor> | Plus, somehow it doesn't work in Chrome, but does in Firefox. |
| 16:51 | <AryehGregor> | Write once run everywhere, huh? |
| 16:53 | <hsivonen> | karlcow: that slide set has the highest concentration of Fielding quotes I've ever seen on a slide set |
| 16:57 | <jgraham> | It looks less like a presentation and more like a sermon from the Gospel according to Roy |
| 18:45 | <AryehGregor> | Ugh, some browsers seem to have magic rendering rules for contenteditable. |
| 18:46 | <AryehGregor> | Especially IE, but I just found one in WebKit too -- behaves differently. |
| 18:46 | <AryehGregor> | (It seems to provide a breaking opportunity, but not collapse.) |
| 18:48 | <TabAtkins> | provides a breaking opportunity in contenteditable? |
| 18:49 | <AryehGregor> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1041 |
| 18:49 | <AryehGregor> | Try removing "contenteditable" and you'll see it changes. |
| 18:49 | <TabAtkins> | Wow. |
| 18:49 | <AryehGregor> | In Chrome 14 dev. |
| 18:49 | <TabAtkins> | That's retarded. |
| 18:49 | <AryehGregor> | Well, it makes some sense if you look at how and why nbsp's are inserted in contenteditable. |
| 18:50 | <AryehGregor> | For instance, if you have <b>foo</b>bar with your cursor between "foo" and "bar", and hit space, WebKit will insert nbsp when it should insert a space. |
| 18:50 | <AryehGregor> | So it looks like an extra bug added to work around other bugs. |
| 18:50 | <AryehGregor> | That's my guess, anyway. |
| 18:50 | <TabAtkins> | So, still retarded. |
| 18:51 | <AryehGregor> | Well, yeah. But I'm not even going to try defining when something should be nbsp and when it should be space -- it's way too complicated if you don't have access to the CSS line boxes. |
| 18:51 | <AryehGregor> | Which WebKit maybe does, so maybe should do better than me. |
| 18:51 | <AryehGregor> | Maybe I'll just have to define something I can't properly add to my JavaScript implementation. |
| 18:56 | <AryehGregor> | Gecko is even crazier. A regular space at the end of a line doesn't collapse, in contenteditable. |
| 18:57 | <AryehGregor> | I don't know why it doesn't just insert nbsp like everyone else. |
| 18:57 | <AryehGregor> | IE is like Gecko. |
| 19:21 | <AryehGregor> | Why is a string index a valid lval if assigning to it doesn't work? I mean, if s is a string, you can do s[0] = "x", but it doesn't actually change s, so why doesn't it throw? |
| 19:22 | <Ms2ger> | What about in strict mode? |
| 19:22 | <AryehGregor> | Bingo. |
| 19:22 | <AryehGregor> | Another reason to always use strict mode. |
| 20:04 | <gsnedders> | AryehGregor: If you can reference something, you can assign to it without throwing. |
| 20:04 | <AryehGregor> | gsnedders, what does "reference" mean? |
| 20:05 | <AryehGregor> | 1 = 0 throws, right? |
| 20:05 | <gsnedders> | AryehGregor: 1 isn't a reference |
| 20:05 | <AryehGregor> | What's a reference, then? |
| 20:05 | AryehGregor | has to read ES someday |
| 20:07 | <gsnedders> | AryehGregor: A reference is a resolved binding of some type, roughly |
| 20:37 | <Hixie> | hsivonen: my rule of thumb is "would including this in new pages waste people's time" |
| 20:48 | <hsivonen> | Hixie: "no" in the yandex case |
| 20:48 | <Ms2ger> | Whose time? :) |
| 20:49 | <Hixie> | hsivonen: then the conformance checker should ok it |
| 20:50 | <Philip`> | I thought all these verification meta things were only meant to be added to your page for a few minutes until the search engine has successfully verified it and then they can be removed, but everyone seems to leave them there forever |
| 20:50 | <Hixie> | hsivonen: how we justify that is somewhat academic, whether we use some process to argue for it or whether we just say "yup, this one isn't following the process but oh well!" is not particularly important |
| 21:13 | <AryehGregor> | Okay, so it turns out nbsp's are a total, complete mess. |
| 21:13 | <AryehGregor> | Because they conflate non-collapsing with non-breaking. |
| 21:13 | <AryehGregor> | We really only want non-collapsing for the contenteditable case. |
| 21:13 | <AryehGregor> | But we get non-breaking too, which has all sorts of nasty side-effects. |
| 21:14 | <TabAtkins> | Yes. |
| 21:14 | <TabAtkins> | Blame early browsers. |
| 21:14 | <TabAtkins> | (For adding the non-collapsing functionality to them.) |
| 21:17 | <AryehGregor> | Observed behavior in OO.org and Word: typing "foo" then lots of spaces then "bar" always ends up with "foo" at the start of a visible line and then "bar" at the start of the next visible line. |
| 21:18 | <AryehGregor> | WebKit behaves that way for contenteditable, because it magically treats nbsp as breakable but non-collapsing. |
| 21:18 | <AryehGregor> | But then it will break as soon as you make it non-contenteditable, of course. |
| 21:18 | <AryehGregor> | Gecko, Opera, and IE all behave in a totally different and much weirder way. |
| 21:18 | <AryehGregor> | (from the user perspective) |
| 21:19 | <AryehGregor> | As does WebKit once you remove contenteditable. |
| 21:19 | <TabAtkins> | Shorter: editing is still totally fucked up. |
| 21:19 | <zewt> | even gmail's editor is obnoxiously broken, and most homebrew ones are just unusable |
| 21:20 | <AryehGregor> | Unicode doesn't even have a space character that has the desired semantics. |
| 21:20 | <AryehGregor> | Well, because collapsing is an HTML thing, I guess. |
| 21:22 | <AryehGregor> | I notice that setting white-space: pre-wrap on the contenteditable region achieves the desired effect in all browsers, more or less. |
| 21:22 | <AryehGregor> | Hmm. |
| 21:27 | <AryehGregor> | So here's a fun thing: if you type a word and it's just long enough to reach the right edge of where you're typing, then you hit space, that inserts an nbsp, so it should actually move the word to the next line. Then it should jump back as soon as you type the next letter, which converts it to a regular space. |
| 21:27 | <AryehGregor> | This actually happens in Opera, but evidently all other browsers cheat somehow, because it doesn't happen for them. |
| 21:28 | <AryehGregor> | Even though if you add an actual to the source, it does happen in IE and Gecko (but WebKit cheats more outrageously, so it doesn't). |
| 21:28 | <AryehGregor> | SIGH. |
| 21:37 | <AryehGregor> | You know, I'm strongly tempted to tell UAs to add [contenteditable] { white-space: pre-wrap } to their UA stylesheets and then drop all this nbsp nonsense. |
| 21:37 | <AryehGregor> | It would make things so much simpler. |
| 21:37 | AryehGregor | writes a mail |
| 22:05 | <AryehGregor> | Sent. |
| 22:09 | <mpilgrim> | heycam|away: https://bugs.webkit.org/show_bug.cgi?id=63011 aligns WebKit with WebIDL to throw TypeError instead of SyntaxError on not enough arguments |
| 22:10 | <mpilgrim> | heycam|away: after that lands, i can start fixing IndexedDB, and the new strictness will no longer be theoretical! |
| 22:20 | <jamesr> | ncsp? |
| 22:21 | <AryehGregor> | ? |
| 22:22 | <heycam> | mpilgrim, awesome! |
| 22:25 | <jamesr> | AryehGregor: non-collapsing space |
| 22:25 | <jamesr> | to go with non-breaking space |
| 22:26 | <AryehGregor> | Which maps to what Unicode character, given that Unicode doesn't know about whitespace collapsing? |
| 22:26 | <jamesr> | 7! |
| 22:27 | <AryehGregor> | If authors were allowed to insert U+0007 into pages and have it work, I think users would be unhappy. |
| 22:29 | <jamesr> | i don't have any serious suggestions, but it seems that if unicode can have a pile of poo character it can have just about anything |
| 22:31 | <jamesr> | is U+0007 bell? |
| 22:32 | <jamesr> | <blink>U+0007</blink> |
| 22:34 | <zewt> | jamesr: heh, well more seriously, adding new characters with special rendering semantics is a whole different beast than adding a dumb poop glyph |
| 22:47 | <annevk> | "We still believe that most sighted keyboard only users can't or don't |
| 22:47 | <annevk> | know how to activate @longdesc but here it's where new Authoring Tools |
| 22:47 | <annevk> | and User Agents Accessibility Guidelines should help filling the gap. " |
| 22:47 | <annevk> | oh please tools, save us now! |
| 22:47 | <Dashiva> | Just wait, longdesc will be the best legacy feature ever after a few more years of development |
| 22:48 | <annevk> | I think it's the only attribute with its own twitter account, that alone should be enough, no? |
| 22:49 | <Dashiva> | That's super accessible |
| 22:50 | <Dashiva> | You can access it both in your browser and with your mobile device |
| 22:50 | <zewt> | there's some irony in something called "longdesc" having its own account on a service notoriously incapable of describing anything long |
| 23:26 | <Philip`> | zewt: Seems quite appropriate, because in both cases you give a URL to the long content |
| 23:43 | <annevk> | maybe DOM Core should also do document.contentType if we do charset et al |
| 23:48 | <Yuhong> | http://www.reddit.com/r/programming/comments/cm02a/you_cant_parse_html_with_regular_expressions/c0tje4z |
| 23:48 | <Yuhong> | "The rules for parsing HTML have evolved into something quite horrific." |
| 23:48 | <Yuhong> | And it certainly don't help that browsers over time have parsed HTML in different ways. |
| 23:49 | <Yuhong> | For example, Mosaic treated tags as commands. For example, <li> outside <ol> would always result in a bullet. |
| 23:51 | <Hixie> | Yuhong: still does! |
| 23:51 | <AryehGregor> | <li> outside -- yeah. |
| 23:51 | <AryehGregor> | Was about to say. |
| 23:52 | <Yuhong> | In quirks mode for compatiblity. IE9 and Mozilla no longer does it in standards mode. |
| 23:52 | <AryehGregor> | orly? |
| 23:52 | <AryehGregor> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cli%3Ehi |
| 23:53 | <Hixie> | if they don't then they're violating the spec :-) |
| 23:53 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%3Cli%3Ehi |
| 23:53 | <AryehGregor> | You said quirks mode, so you can also do standards mode if you like: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%3Cli%3Ehi |
| 23:53 | <AryehGregor> | Same result. |
| 23:53 | <Philip`> | I get no bullet point for the latter, in FF 4.0.1 |
| 23:54 | <AryehGregor> | Oh. |
| 23:54 | <AryehGregor> | Nor do I. |
| 23:54 | <Philip`> | (There's still an li DOM node, it's just not styled) |
| 23:54 | <Yuhong> | Nor do I either. |
| 23:54 | <AryehGregor> | That seems evil. |
| 23:54 | <AryehGregor> | How could that be? |
| 23:54 | <AryehGregor> | It's display: list-item. |
| 23:54 | <AryehGregor> | Sounds like a Firefox bug. |
| 23:54 | <Hixie> | yeah you do |
| 23:54 | <Hixie> | it's just off the side of the screen |
| 23:54 | <Hixie> | add some margins |
| 23:54 | <AryehGregor> | Ah. |
| 23:55 | <AryehGregor> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%3Cli%20style%3Dmargin-left%3A1em%3Ehi |
| 23:55 | <AryehGregor> | There you go. |
| 23:55 | <AryehGregor> | It seems like quirks mode triggers list-style-type: inside. |
| 23:55 | <Hixie> | it's a list-style-position issue iirc |
| 23:55 | <AryehGregor> | -position, whatever. |
| 23:55 | <Hixie> | yeah |
| 23:56 | <Philip`> | quirk.css says "li { list-style-position: inside }" |
| 23:56 | <AryehGregor> | li { list-style-position: inside } ..., ul li, ... { list-style-position: inherit } in Gecko's default CSS. |
| 23:56 | <AryehGregor> | In quirks. |
| 23:56 | <AryehGregor> | Mystery solved. |
| 23:57 | <AryehGregor> | I wonder if that's documented anywhere. |
| 23:57 | <Yuhong> | And as it happens, someone mentioned <wow that='is a > great idea'>. |
| 23:57 | <Yuhong> | And as it happens, Mosaic and Netscape 1.x would consider the first > to be the end of a tag. |
| 23:58 | <Philip`> | https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior documents it by reference to quirk.css |
| 23:58 | <AryehGregor> | Philip`, I really meant documented in a spec. |
| 23:59 | <annevk> | ah shit |
| 23:59 | <annevk> | why does Web IDL not link to the editor's draft? |
| 23:59 | <annevk> | heycam, ^^ |