| 00:00 | <Hixie> | on a more productive note, does anyone know where we create the javascript global environment for browsing contexts? |
| 00:00 | <Hixie> | i'm drawing a blank here |
| 00:10 | Hixie | tries to figure out where it should be happening, since it doesn't appear to be happening anywhere |
| 00:10 | <Hixie> | sweet lord what a tangled web we weave |
| 00:10 | <Hixie> | ok so one Window can have two Documents |
| 00:10 | <Hixie> | but can one Document ever have two Windows? |
| 00:10 | <Hixie> | oh, right, document.open() |
| 00:10 | <Hixie> | crap |
| 00:11 | <Hixie> | jesus this is messed up |
| 00:12 | <Hixie> | i guess the question is, given that all singletons and interface objects, etc, get reset when you do document.open(), is it still nonetheless the same javascript global environment? |
| 00:16 | <Hixie> | i like how y'all are full of opinions on highly complicated legal matters like which license is best but when it comes to our bread and butter y'all shut up :-P |
| 00:22 | tantek | was away editing wiki pages |
| 00:23 | <tantek> | Hixie, http://wiki.whatwg.org/wiki/Test_cases updated |
| 00:23 | <tantek> | and this section added as well: http://wiki.whatwg.org/wiki/Testsuite#How_to_license_your_test_suite |
| 00:23 | <tantek> | feel free to tweak |
| 00:25 | <Hixie> | cool |
| 00:25 | <Hixie> | (anyone know of a way to test is a plugin is being instantiated when the plugin is invisible? my test flash files all just display words like "PASS", they don't have audio or expose APIs...) |
| 00:26 | <tantek> | at least we have something to point to when people ask us how to do it |
| 00:26 | <tantek> | Hixie, would a plugin that just changed the <title> count as invisible? |
| 00:29 | <heycam> | Hixie, pong. was that the bug 15158 you just changed? |
| 00:30 | <Hixie> | tantek: sure, do you have one? |
| 00:30 | <Hixie> | heycam: yeah |
| 00:30 | <heycam> | will review |
| 00:30 | <Hixie> | heycam: please see the diff and let me know how crazy i am |
| 00:30 | <abarth> | Hixie: I can try to answer these questions |
| 00:30 | tantek | avoids writing plugin code. |
| 00:31 | <abarth> | Hixie: There should be a one-to-one relationship between DOMWindow and Document |
| 00:31 | <Hixie> | i wrote a debug NPAPI plugin long ago when reverse engineering <object>, but I don't really want to dig it up, let alone recompile it for 64 bit :-) |
| 00:31 | <Hixie> | abarth: there definitely isn't :-) |
| 00:31 | <abarth> | Hixie: why not? |
| 00:31 | <Hixie> | abarth: e.g. Document objects get reused when you call document.open(), even though the Window changes, and the Window gets reused for two Document objects when you load a page into a frame with about:blank loaded in certain cases. |
| 00:32 | <Hixie> | (also there's no such thing as DOMWindow, it's just Window :-P) |
| 00:32 | <abarth> | Hixie: You can dance around those, if you want |
| 00:32 | <tantek> | perhaps there's an Actionscript Hello World DOM example somewhere that could be modified to set document.title="PASS"; |
| 00:32 | <abarth> | in the second case, you can just move all the properties over |
| 00:33 | <abarth> | and update the WindowProxy as usual |
| 00:33 | abarth | goes and checks on the first case |
| 00:34 | <Hixie> | abarth: well fundamentally my question is the same one as for heycam... basically, do we need to say when we create the global environment? |
| 00:34 | <Hixie> | or rather, where should we say to |
| 00:34 | <Hixie> | see the most recent checkin for the hack that i came up with |
| 00:34 | <Hixie> | in the meantime |
| 00:35 | <Hixie> | anyway: afk for a bit, heading home |
| 00:35 | <abarth> | Hixie: in the first case, it looks like we just remove event listeners |
| 00:35 | <hoolter> | Why do @src-full <script>s need a closing tag? |
| 00:36 | <abarth> | Hixie: yeah, the global variables are still there: |
| 00:36 | <abarth> | > window.foo ="hi" |
| 00:36 | <abarth> | > document.open() |
| 00:36 | <abarth> | > document.write("<script>alert(window.foo)</script>") |
| 00:39 | <hoolter> | abarth: not sure what the idea is, but you'll want to actually do doc.write('<script>alert(win.foo)<'+'/sc'+'ript>).... |
| 00:39 | <abarth> | hoolter: oh, i was typing in the web inspector |
| 00:40 | <hoolter> | abarth: ah, ok. |
| 00:42 | <tantek> | Hixie, re: the relevant people at W3C, it appears that this W3C page makes it clear that W3C test suites are supposed to all be available under BSD for implementations etc. : http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright |
| 00:42 | <tantek> | (more than just the CSSWG) |
| 00:43 | <tantek> | so whoever is saying the W3C HTML5 tests are not liberally licensed (or should / should not be) or so might want to take a look at that |
| 00:48 | <MikeSmith> | tantek: yeah that's my understanding as well |
| 00:49 | <MikeSmith> | tantek: I think the message Hixie has in mind was http://lists.w3.org/Archives/Public/public-test-infra/2012JulSep/0031.html |
| 00:49 | <MikeSmith> | Kris Kruger from Microsoft |
| 00:49 | <MikeSmith> | saying "the license issue is a blocker" |
| 00:49 | <MikeSmith> | d |
| 00:50 | <MikeSmith> | I don't understand what license issue he means |
| 00:55 | <MikeSmith> | tantek: I suspect that he just means the need for people to complete the license grant at https://www.w3.org/2002/09/wbs/1/testgrants2-200409/ |
| 00:56 | <MikeSmith> | but we can have people complete that even if we host the tests elsewhere |
| 00:56 | <MikeSmith> | the location where they're hosted is orthogonal to the license agreement |
| 00:57 | <MikeSmith> | I hope nobody's suggesting we accept test cases without having license grants on file from the people who contributed them |
| 00:58 | <MikeSmith> | for one thing, if we don't have that, it might prevent other free-software projects from being able to redistribute the test suites |
| 00:59 | <MikeSmith> | Debian project for example are keen on checking to make sure everything they package is in fact free, with documentation about who contributed and a record of them agreeing to freely license their contributions |
| 01:25 | <gsnedders> | MikeSmith: Really? That surprises me given the relatively small number of projects that require CLAs. |
| 01:25 | <MikeSmith> | gsnedders: well, that ask at least |
| 01:25 | <MikeSmith> | I don't think the require the details always, but they prefer them |
| 01:26 | <MikeSmith> | I know because I've been contacted before by Debian packagers asking for records |
| 01:26 | <gsnedders> | Yeah. I can see there's aso going to be more doubt over higher-profile projects where there's more to gain by getting stuff in without proper grants. |
| 01:27 | <MikeSmith> | right |
| 01:27 | <MikeSmith> | and especially when some contributors are working for companies that have software patents |
| 01:32 | <jamesr_> | i thought CLAs are typically about copyright, not patents |
| 01:35 | <MikeSmith> | jamesr_: yeah true. so maybe my comment is a non-sequitor |
| 01:57 | <gsnedders> | jamesr_: Combined with something like the Apache License, though, it would be. |
| 02:16 | <tantek> | MikeSmith from reading that thread I don't understand what the problem is either |
| 02:16 | <tantek> | I just tell folks to contribute the entirety of their test suites to the public domain with CC0 and then it lets anyone else do whatever with them. |
| 02:17 | <tantek> | i.e. do this and don't worry about it: http://wiki.whatwg.org/wiki/Testsuite#How_to_license_your_test_suite |
| 02:17 | <tantek> | if someone else wants to incorporate your work and relicense with BSD (e.g. W3C) great. but keep the core in the public domain where the community iterates on it. |
| 02:18 | <tantek> | so to that extent, I'd advocate for putting tests suites on github with PD/CC0 and then let W3C or whoever else incorporate them downstream |
| 02:29 | <tantek> | BTW with regards to getting contributor agreements on github, since github itself doesn't have a contributor agreement mechanism, here's what I've done with one of my projects: https://github.com/tantek/cassis/blob/master/contributors.txt |
| 07:08 | <jgraham> | Hixie: Testsuites are W3C/BSD dual licensed (I guess someone else already said that... reading) |
| 07:11 | <jgraham> | Also, it is the same global environment after document.open isn't it? |
| 07:24 | <jgraham> | (and what makes you think I would contribute to, or encorage others to contribute to, a testsuite with crappy licensing :) |
| 08:16 | <odinho> | Ms2ger: startTime did exist before. They probably found some old TR to cuddle up with. |
| 08:19 | jgraham | remembers he was having a nightmare about being at a HTMLWG F2F |
| 08:19 | odinho | want a wiki user. |
| 08:20 | <jgraham> | annevk and rubys were there. And I turned up late. This is all I remmeber. |
| 08:26 | <odinho> | Hehe. My first (and only) htmlwg meeting, me and annevk was always super early because we were badly out of sync with the time :] |
| 08:54 | <Ms2ger> | odinho, I see |
| 08:54 | <Ms2ger> | odinho, the fun part is that the test passes because 0 == undefined |
| 08:54 | <jgraham> | Hahaha |
| 08:54 | <odinho> | cool |
| 08:54 | <odinho> | some forward thinking on their part there |
| 08:55 | <jgraham> | Pointer? |
| 08:55 | <Ms2ger> | tests/approved/video/video_007.htm |
| 08:57 | <Ms2ger> | Also fun: video_001.htm and video_006.htm are identical |
| 08:57 | <odinho> | Can't be too sure, you know. |
| 08:57 | <jgraham> | That seems to be from intel? |
| 08:58 | <jgraham> | Also it is obviosuly rejected on the basis it doesn't use testharness.js |
| 08:58 | <jgraham> | Oh wait |
| 08:58 | <jgraham> | I am confused again |
| 08:58 | <jgraham> | Silly silly hgweb |
| 08:58 | <odinho> | Yeah, it is supremely silly. |
| 08:58 | <odinho> | When I had the last commit, I had someone ask me about a totally random test. |
| 09:48 | <hoolter> | Why do @src-full <script>s need a closing tag? |
| 09:49 | <Ms2ger> | Because otherwise the rest of the page is eaten |
| 09:55 | <AryehGregor> | Hmm. So why is cp --reflink=auto not the default in GNU cp? |
| 09:55 | AryehGregor | is looking to start using btrfs |
| 09:55 | <AryehGregor> | Maybe I should ask in #btrfs instead of spamming random channels. |
| 09:55 | <AryehGregor> | Novel concept. |
| 10:11 | <odinho> | AryehGregor: Sounds like work. |
| 10:11 | <AryehGregor> | If it were work, I would be paid for it. :) |
| 10:11 | <odinho> | I've been running btrfs for a long time though. Totally nice. |
| 10:12 | AryehGregor | has ordered two SSDs to move all his code onto, since he's tired of waiting for operations like "hg qpush" that scan the disk |
| 10:12 | AryehGregor | figures he'll make it btrfs just for kicks, while he's at it, since it's all backed up and readily replaceable |
| 10:13 | jgraham | spends very little of his life thinking "oh here's a problem that would be solved if only I had a different filesystem" |
| 10:14 | <AryehGregor> | I like filesystems! They're interesting. |
| 10:15 | <AryehGregor> | Also, snapshots and cp --reflink are really nice. |
| 10:15 | <AryehGregor> | I'm betting cp -a --reflink on my SSDs will copy an entire mozilla-central checkout (a few gigs) in under a second. |
| 10:15 | <AryehGregor> | Which I have to do periodically, like to recover from corruption. |
| 10:15 | <jgraham> | I think they are probably theoretically very interesting |
| 10:16 | <AryehGregor> | Because Mercurial, hey, Mercurial's all about randomly corrupting your data. |
| 10:16 | <AryehGregor> | Also, there have been times when I'd have loved a snapshot that I could easily roll back to. |
| 10:16 | <jgraham> | YOu gave up on git? |
| 10:16 | <AryehGregor> | But rsnapshot is ridiculously too expensive. |
| 10:16 | <AryehGregor> | No, but Mozilla uses hg, so I was giving hg a chance to prove that it's not intolerable. |
| 10:16 | <AryehGregor> | I've more or less given up, hg is just fundamentally broken. |
| 10:17 | <AryehGregor> | But I have to spend some time to switch to git and change my workflow accordingly. |
| 10:17 | <AryehGregor> | hg-git has been flaky in my experience. |
| 10:18 | <jgraham> | Were you using the cdouble-approved workflow? |
| 10:18 | <AryehGregor> | What? |
| 10:18 | <jgraham> | http://www.bluishcoder.co.nz/2011/04/16/my-git-workflow-for-mozilla-development.html |
| 10:19 | <hoolter> | Ms2ger: but why can't the parser be smart about whether it has a @src or not? |
| 10:19 | <AryehGregor> | Hmm, interesting. |
| 10:20 | <AryehGregor> | hoolter, it can, but the decision was made like 15 years ago and it's too late to change it. |
| 10:20 | <jgraham> | My experience with the W3C repos is that workflow, which avoids using the push/pull in hg-git works better than workflows that depend on those) |
| 10:20 | <jgraham> | s/)// |
| 10:20 | <AryehGregor> | Yeah, that workflow makes a lot of sense. |
| 10:20 | <Ms2ger> | Speaking of W3C repos |
| 10:20 | <Ms2ger> | Do you guys have web audio tests? |
| 10:20 | <AryehGregor> | Use git read-only for development, and push actual patches using hg directly. |
| 10:22 | <jgraham> | Ms2ger: What do you mean Web Audio? |
| 10:22 | <jgraham> | Do you mean the Google thing, or the Mozilla thing or the <audio> element? |
| 10:22 | <jgraham> | Or some other thing? |
| 10:38 | <Ms2ger> | The Mozilla thing, I guess |
| 13:04 | <hoolter> | AryehGregor: why is it too late to change it though? |
| 13:05 | <AryehGregor> | hoolter, because countless millions of pages almost certainly depend on it and will break if we change it? |
| 13:05 | <AryehGregor> | And users tend to stop using browsers that break the pages they visit? |
| 13:06 | <AryehGregor> | And browsers compete intensely, so that even a modest number of users who stop using a browser is something that everyone tries to avoid at all costs? |
| 13:06 | <jgraham> | I think Opera allowed that syntax for a while and I am not sad we stopped allowing it |
| 13:06 | <AryehGregor> | Did it have compat issues? |
| 13:07 | <jgraham> | Almost certainly, but I don't have specific bugs in mind |
| 13:08 | <jgraham> | HTML parsing really needs nothing more than people to just leave it alone |
| 13:08 | <AryehGregor> | Yes. |
| 13:08 | <jgraham> | Incremental gains in friendliness at the risk of compat breakage are not worth it |
| 13:22 | <AryehGregor> | Trying to make HTML parsing more predictable and user-friendly is putting lipstick on a pig anyway. |
| 14:46 | <Hixie> | othermaciej, hsivonen: i'm baffled by this idea of reusing <meta> or <link>. Should we just have every void element from now on use <meta>? Even though it's already overloaded a zillion ways to sunday? |
| 14:53 | <jgraham> | Hixie: Yes, especially if it is going in <head> |
| 14:54 | <jgraham> | Just like we reuse <input> for compat reasons rather than inventing <datepicker> |
| 14:54 | <Hixie> | that sounds crazy to me |
| 14:55 | <jgraham> | Why? |
| 14:55 | <Hixie> | the cost of a new void element is de minimis compared to the cost of overloading these elements more |
| 14:55 | <jgraham> | That's really not true |
| 14:55 | <jgraham> | The cost of a new void element to us is huge |
| 14:55 | <Hixie> | o_O |
| 14:55 | <jgraham> | I mean it's trivial to add in the code |
| 14:56 | <jgraham> | But every day that we don't ship it and someone else does it's a compat liability |
| 14:56 | <jgraham> | Which just doesn't exist with an existing void element |
| 14:56 | <Hixie> | we've added tons of void elements over the years |
| 14:56 | <jgraham> | Not really |
| 14:56 | <jgraham> | We added <source> which had the </video> get-out-of-jail-free card |
| 14:57 | <Hixie> | apple added <canvas> and the only reason that was a problem is that we ended up not wanting it to be void |
| 14:57 | <jgraham> | I can't think of anything that we added to <head> for over a decade |
| 14:58 | <Hixie> | <wbr> was added at some random point, as was <keygen> |
| 14:58 | <Hixie> | we added <track> at some point, and it, like <source>, is essentially in the <head> of a block of content intended specifically for legacy UAs |
| 14:58 | <jgraham> | <keygen> was added in netscape 4 times, so also long ago, and before CSS or scripting took off |
| 14:59 | <Hixie> | i really don't see the problem with adding something to <head> |
| 14:59 | <jgraham> | These days the compat risks are much higher because everything depends on the precise form of the DOM |
| 15:00 | <Hixie> | i'm highly skeptical |
| 15:00 | <Hixie> | if there was any evidence that'd be one thing |
| 15:00 | <jgraham> | I'm highly skeptical that it's safe |
| 15:00 | <Hixie> | but this is just FUD, imho |
| 15:00 | <Hixie> | we should take risks, not play things so safe that we make the language even more ludicrous than it already is |
| 15:01 | <jgraham> | Well we have a whole design principle about back-compat and three browser vendors telling you they don't like the design :) |
| 15:01 | <Hixie> | this doesn't break any existing content |
| 15:02 | <jgraham> | It also doesn't degrade gracefully |
| 15:02 | <Hixie> | come now |
| 15:02 | <Hixie> | it degrades fine |
| 15:02 | <jgraham> | It you are seriously careful about how you use it |
| 15:02 | <Hixie> | you don't even have to be careful |
| 15:02 | <jgraham> | Which I don't trust authors to be |
| 15:03 | <Hixie> | any problems you might run into are immediately obvious |
| 15:03 | <Ms2ger> | If you test in Opera |
| 15:03 | <jgraham> | If you test on a browser that doesn't have support |
| 15:05 | <jgraham> | Ms2ger: Or Mobile Firefox, for example |
| 15:05 | <Ms2ger> | Meh, I don't care about Mobile Firefox |
| 15:05 | <jgraham> | Just as well you don't wnt to be paid by MozCo then ;) |
| 15:06 | <Ms2ger> | I think I'll do fine :) |
| 15:06 | <jgraham> | Hixie: Anyway the sad truth is that, particularly on mobile, developers can't be trusted to test well |
| 15:06 | <Hixie> | this cost is so small i'm struggling to care at all |
| 15:07 | Ms2ger | grumbles about not being able to use std::numeric_limits<T>::min()/max() for [Clamp] |
| 15:07 | <Hixie> | compared to the cost of never being able to add more elements |
| 15:07 | <Hixie> | we've added some before without any trouble |
| 15:07 | <Ms2ger> | Hixie, more *void* elements |
| 15:07 | <Hixie> | this is completely hypothetical |
| 15:07 | <jgraham> | We added one in over a decade |
| 15:07 | <Hixie> | we've added at least two just to <video> |
| 15:08 | <Hixie> | where they specifically affect legacy UAs |
| 15:08 | <jgraham> | Oh, is track also void? |
| 15:08 | <Hixie> | and we added canvas before it was changed |
| 15:08 | <jgraham> | But the </video> container limits the damage there |
| 15:08 | <Hixie> | and wbr and keygen and img before that |
| 15:08 | <jgraham> | and void canvas wasn't widely deployed |
| 15:08 | <Hixie> | it limits the damage _specifically to legacy UAs that don't support the element_ |
| 15:09 | <jgraham> | and wbr and keygen and img are over a decade ago and predate anyone using scripts or css selectors |
| 15:09 | <Hixie> | if we try this and find that it really causes damage, then sure, it would make sense to avoid it |
| 15:09 | <jgraham> | So they are super-weak examples |
| 15:09 | <Hixie> | but avoiding it just because of theoretical concerns is silly and chicken |
| 15:09 | <Hixie> | my point is that however weak, they are examples of it working |
| 15:09 | <Hixie> | we have _zero_ examples of it not working |
| 15:09 | <jgraham> | My point is that they are irrelevant |
| 15:09 | <Hixie> | not even weak ones |
| 15:13 | <darobin> | or we could just grant /> magical close behaviour and require it on new void elements! |
| 15:13 | darobin | runs away giggling |
| 15:14 | <jgraham> | (btw, I don't think it's reasonable to characterise arguments as "chicken" when you are not one of the parties assuming any of the risk) |
| 15:16 | <Hixie> | my salary is indirectly driven from the success of four browser vendors and of the web platform as a whole, and my ability to perform my job is directly related to how much browser vendors trust me which would drop if i was wrong, so i wouldn't say i'm not assuming any of the risk |
| 15:37 | <dglazkov> | good morning, Whatwg! |
| 15:37 | <dglazkov> | whoa, excellent discussion on tags |
| 15:38 | <MikeSmith> | are we any closer to interoperability on drag and drop than we were when ppk wrote http://www.quirksmode.org/blog/archives/2009/09/the_html5_drag.html 3 years ago? |
| 15:39 | <Hixie> | over the last three years UAs have definitely changed their drag and drop implementations |
| 15:39 | <Hixie> | whether we're any closer, i dunno |
| 15:39 | <Hixie> | i did notice that webkit implemented the dropzone thing, but for reasons that baffle me they prefixed it |
| 15:40 | <jgraham> | We have a pile of tests that we ought to release |
| 15:40 | <jgraham> | But for obviosu reasons they are mostly manual tests |
| 15:41 | <odinho> | We have a runner :] |
| 15:41 | <dglazkov> | Hixie: prefixing in WebKit is a bit of a cargo cult |
| 15:43 | <jgraham> | odinho: I heard something about perl scripts and then got scared |
| 15:43 | <jgraham> | Automating dragging from the desktop to the browser seems very difficult to make reliable to me |
| 15:44 | <odinho> | jgraham: Oh, scary indeed. I just see the tests running every day, because giorgic's screen is very viewable from here. |
| 15:46 | <jgraham> | Anyway, I think it's better to go with the simpler interpretation that "they're manual tests" |
| 15:46 | <odinho> | jgraham: Sure |
| 15:53 | <AryehGregor> | Wait, so what's the big problem specifically with void tags? I'd have thought the bigger problem would be introducing new tags that are allowed in <head> -- if authors aren't careful to put them after things like <title>, which they won't be, it will break the page in browsers that treat them as an implicit <body> start, no? |
| 15:54 | <AryehGregor> | New void tags will break things like .lastChild, I guess. |
| 15:54 | <AryehGregor> | But I'm actually moderately skeptical that that would be a real problem in practice. |
| 15:54 | <AryehGregor> | In particular, the compat hit only hits old browsers, right? |
| 15:55 | <AryehGregor> | So as long as all browsers coordinate to deploy support at roughly the same time, it doesn't seem like a big problem. |
| 15:55 | <AryehGregor> | Authors don't deploy new features *that* fast. |
| 15:56 | <Hixie> | especially with browsers moving to release cycles measured in weeks rather than years |
| 15:56 | <Ms2ger> | Except IE |
| 15:56 | <Ms2ger> | And except Safari |
| 15:56 | <Ms2ger> | And except every mobile browser |
| 15:57 | <Hixie> | i said "moving", not that they were all there already |
| 15:57 | <jgraham> | AryehGregor: When did browsers ever coordinate to deploy things at the same time? |
| 15:57 | <AryehGregor> | jgraham, doesn't mean they can't. |
| 15:57 | <jgraham> | But yes, for the specific case of new elements in <head> there are even more problems than new elements in general |
| 15:57 | <Ms2ger> | In the nineties, I hear |
| 15:57 | <Hixie> | HTML parser was implemented by pretty much everyone very close to each other |
| 15:57 | <AryehGregor> | Also: why do we care if it hurts IE and Safari? :) |
| 15:57 | <jgraham> | +void |
| 15:58 | <AryehGregor> | Hixie, um, a couple years apart, no? |
| 15:58 | <jgraham> | Hum? IE still hasn't shipped that |
| 15:58 | <jgraham> | And won;t ever on the platforms that most IE users currently use |
| 15:58 | <Hixie> | AryehGregor: that's about as close as i can imagine it happening |
| 15:58 | <AryehGregor> | But really, I don't see the big risk in something where the compat hit will only affect old browsers. |
| 15:59 | <AryehGregor> | I'd even say compatibility of new pages with old browsers should be an explicit non-goal. |
| 15:59 | <AryehGregor> | Obviously pages that use new features might not work in old browsers if they're not specifically tested. |
| 15:59 | <jgraham> | AryehGregor: You mean "any browser that doesn't implement the feature yet" |
| 15:59 | <AryehGregor> | jgraham, well, yes, but if you're just worried about that, you can always do a quick parser fix to avoid any compat fallout. |
| 15:59 | <AryehGregor> | You don't have to implement the interfaces or anything, even as stubs. |
| 16:00 | <AryehGregor> | It should be the work of like an hour or two. |
| 16:00 | <Hixie> | anyone have any way to test if a plugin is instantiating or when the plugin isn't visible? |
| 16:00 | <jgraham> | and I think it is very problematic to design features in ways that favours accidential breakage even if there is no need for the whole page to fail |
| 16:01 | <jgraham> | AryehGregor: I would absolutely advocate us doing that if we are forced to. |
| 16:01 | <Hixie> | s/or/or not/ |
| 16:01 | <jgraham> | I don't want to be forced to |
| 16:01 | <AryehGregor> | jgraham, why not? What's the cost? |
| 16:01 | <Hixie> | you wouldn't be forced to |
| 16:01 | <Hixie> | there just isn't a real risk here imho |
| 16:01 | <jgraham> | Hixie: If you insist on using this design and webkit deploy it we would be forced to |
| 16:01 | <AryehGregor> | Especially for regular old void elements, which can only cause serious failures in relatively uncommon circumstances. |
| 16:02 | <Hixie> | jgraham: i highly doubt it |
| 16:02 | <AryehGregor> | Hixie, I think adding new elements to <head> is a more serious risk, though. All that would take to break non-implementing browsers is authors putting it before the <title> or something. |
| 16:02 | <jgraham> | Hixie: Under those circumstances I would change our parser |
| 16:03 | <Hixie> | AryehGregor: how so? |
| 16:03 | <Hixie> | jgraham: (on the other hand "if you insist" on it using <meta> or <link> then we have a language that's even harder to understand, forever. not clear to me that you're optimising for the right thing. potential transient risk vs bad language forever.) |
| 16:03 | <AryehGregor> | Hmm, so <title> still works if it's in the <body>? |
| 16:03 | <jgraham> | Hixie: Now you sound like a member of the XHTML 2 WG |
| 16:03 | <AryehGregor> | Yeah, I was going to say. |
| 16:04 | <jgraham> | I don't think <link re=intent> or <link intent> is hard to understand |
| 16:04 | <AryehGregor> | Since when does the WHATWG support long-term hypothetical benefits over short-term implementability? |
| 16:04 | <Hixie> | AryehGregor: everything still works in the <body>, there are too many pages that have a random non-head character (e.g. two BOMs) as the first character |
| 16:04 | <AryehGregor> | Ah, okay. |
| 16:04 | <AryehGregor> | Then I guess I don't see a problem. |
| 16:04 | <Hixie> | jgraham: it doesn't fit with <link>'s processing model at all |
| 16:05 | <jgraham> | Hixie: Is that a practical concern or a spec-author concern? |
| 16:05 | <Hixie> | and re the xhtml2 insult (:-P), there's a world of difference between caring about both transitions and long-term quality and not caring at all about transition |
| 16:05 | <Hixie> | so i don't think it's at all equivalent |
| 16:06 | <Hixie> | jgraham: consider the messes that <input> or <object> are because of overloading already |
| 16:06 | <Hixie> | jgraham: or indeed, <meta> already |
| 16:06 | <jgraham> | <input> is a success story |
| 16:06 | <jgraham> | <object> is not ofc |
| 16:06 | <Hixie> | jgraham: yes, it causes all kinds of problems for authors. tutorials and documentation are all kinds of complicated because of it |
| 16:07 | <Hixie> | <input> is a success story for us, but i don't think most authors see it that way |
| 16:07 | <Hixie> | and to be honest, it's a success story partially because of our heroic work trying to keep it sane in wf2 and html, when adding new features |
| 16:07 | <Hixie> | which was no small feat imho |
| 16:08 | <jgraham> | I don't see why <link> couldn't also be a success. This is a much smaller problem (we are trying to add one feature not a dozen) |
| 16:08 | <Hixie> | <link> is already a confusing mes |
| 16:08 | <Hixie> | s |
| 16:08 | <dglazkov> | <input> is a "despite all odds" success story. The basic design sucks. I hope everyone agrees on that. |
| 16:08 | <Hixie> | hear hear |
| 16:08 | <jgraham> | s/input/HTML/ |
| 16:10 | <jgraham> | I don't think we could have done better than <input> in the circumstances, and I think we will get burnt by trying to go for the more theoretically pure approach now |
| 16:10 | <Hixie> | i really couldn't care less about theoretically pure, personally |
| 16:10 | <Hixie> | this is about authors |
| 16:10 | <Hixie> | and keeping the language sane and understandable for authors |
| 16:10 | <dglazkov> | I don't understand "theoretic" argument. It's what authors would expect |
| 16:10 | <dglazkov> | that's right |
| 16:11 | <jgraham> | They will expect that adding an <intent> tag will break their page in all old browsers? |
| 16:12 | <dglazkov> | there's a bit of a Stockholm-syndrome stuff happening here. Compatibility and don't-break-the-Web is one thing, but preferring to wallow in the mud just seems wrong. |
| 16:14 | <Hixie> | adding an <intent> tag will not "break their pages in all old browsers", that's complete hyperbole |
| 16:15 | <jgraham> | Shifting all the elements after the <intent> tag to a different place in the DOM seems highly likely to break the page |
| 16:18 | <Hixie> | i just went to opera.com, microsoft.com, and maps.google.com in opera, in each case i viewed the source and added an <intent> at the top of the page, and applied the changes. in no cases could i notice the slightest breakage. |
| 16:18 | <Hixie> | (except in maps where putting it before the doctype switched te quirks mode) |
| 16:18 | <Hixie> | (but moving it to the <head> fixed that) |
| 16:19 | <Hixie> | what page is it that is going to break? |
| 16:19 | <Hixie> | cnn.com also unaffected as far as i can tell |
| 16:19 | <Hixie> | (testing in opera) |
| 16:20 | <Hixie> | google login page also unaffected |
| 16:21 | <jgraham> | Sorry, I don't have time to look for examples now; I have to go (in general I would expect scripts to be more likely to break than other things) |
| 16:21 | <darobin> | <input> is definitely not a success story for authors |
| 16:21 | <darobin> | any DOM mangling inside forms is painful |
| 16:21 | <darobin> | not to mention styling |
| 16:21 | <Hixie> | plus.google.com did fall apart, i'll grant you that |
| 16:22 | <Hixie> | but in such a drastic way that it's hard to believe they wouldn't notice :-) |
| 16:23 | <Hixie> | youtube seems unaffected |
| 16:23 | <dglazkov> | Hixie: I think it's an interesting excursion that could be documented in a G+ post :) |
| 16:23 | <dglazkov> | so that we could refer to it later |
| 16:23 | <dglazkov> | hint hint |
| 16:24 | <Hixie> | twitter home page login screen unaffected |
| 16:24 | <Hixie> | twitter logged in home page unaffected |
| 16:24 | <Hixie> | what other pages could plausibly give intents? |
| 16:25 | <dglazkov> | flickr? |
| 16:25 | <dglazkov> | picnick? |
| 16:25 | <darobin> | pretty much any page, really :) |
| 16:25 | <Hixie> | definitely not any page |
| 16:25 | <darobin> | |
| 16:25 | <Hixie> | (e.g. why would the second page of the html spec have an intent?) |
| 16:25 | <darobin> | definitely not all pages, but very arbitrary pages could |
| 16:26 | <Hixie> | google search results unaffected |
| 16:26 | <darobin> | the pick issues intent |
| 16:26 | <Hixie> | flickr seems unaffected |
| 16:26 | <Hixie> | flickr home page, i should say |
| 16:27 | <darobin> | |
| 16:27 | <darobin> | any calendar system |
| 16:28 | <Hixie> | flickr pic page also unaffected |
| 16:28 | <Hixie> | i thought it was broken at first but flickr's pic page these days is just ugly, it's unrelated to my adding <intent> :-P |
| 16:29 | <Hixie> | picnic seems to have been shut down |
| 16:30 | <Hixie> | i don't have a facebook login, but facebook's login page seems unaffected |
| 16:30 | <Hixie> | calendar.google.com seems unaffected |
| 16:31 | <Hixie> | linkedin's login page seems unaffcted |
| 16:31 | <othermaciej> | Hixie: the fact that <canvas> was a void element became a huge compat problem for us after others shipped it as non-void |
| 16:32 | <Hixie> | othermaciej: yeah, but that's the opposite problem. making it void in the first place didn't cause you problems. |
| 16:32 | <othermaciej> | Hixie: so I'm not sure that it's a good example of it being ok to add void elements |
| 16:32 | <Hixie> | live dom viewer unaffected |
| 16:32 | <othermaciej> | Hixie: well, the content authored assuming it was void broke in implementations where it was not |
| 16:32 | <othermaciej> | Hixie: in severe ways |
| 16:33 | <Hixie> | othermaciej: i agree 100% that we shouldn't go void then change to not-void unless there's a stunningly good reason (as there was with canvas) |
| 16:33 | <othermaciej> | Hixie: so the compat cost of having a difference is very high, and introducing a new void element creates at least a temporary transition time when there is a cross-browser difference |
| 16:33 | <Hixie> | so far the only page i've been able to break by adding an <intent> in the head is plus.google.com, and it broke so hard that it would be impossible for the team not to notice it and fix it. |
| 16:34 | <Hixie> | reddit unaffected |
| 16:34 | <Hixie> | i'm running out of sites to test here |
| 16:35 | <Hixie> | baidu search results unaffected |
| 16:36 | <Hixie> | maps.bing.com unaffected |
| 16:36 | <Hixie> | store.apple.com seems unaffected |
| 16:37 | <Hixie> | based on this research i remain unconvinced that there is a real compat risk |
| 16:37 | <Hixie> | or rather |
| 16:37 | <Hixie> | i remain unconvinced that the compat risk is higher than the value of the new element. |
| 16:38 | <Hixie> | (i agree that there's a risk and that there will be breakage, just not enough to justify a long-term wart) |
| 16:40 | <darobin> | +1, we jumped through the hoops trying to express <intent> with a bazillion other syntaxes and all of them just break down in usability rather quickly |
| 16:41 | <othermaciej> | so you know your change breaks at least one major site |
| 16:41 | <Hixie> | a site that would never ship the change without catching and fixing the problem |
| 17:15 | <AryehGregor> | othermaciej, <canvas> broke not because other browsers treated it as non-void, but because they treated it as non-void *and ignored the contents*, right? Treating it as an unrecognized tag isn't a comparable failure mode. |
| 17:16 | <AryehGregor> | Hixie, but the methodology of your testing inherently excluded any sites that broke in not-totally-obvious ways, because you wouldn't have noticed them if it weren't totally obvious. |
| 17:16 | <AryehGregor> | So what you're really saying is that the only sites that broke in such obvious ways that you immediately noticed broke in such obvious ways that they would have been fixed before shipping. |
| 17:16 | <AryehGregor> | That's not a particularly compelling argument. |
| 17:16 | <othermaciej> | AryehGregor: I don't know if <canvas> is fully analogous to this case at all; I merely wanted to rebut the claim that it's an example showing it's ok to add void elements |
| 17:16 | <AryehGregor> | You'd have to make sure that all the page functionality worked. |
| 17:17 | <AryehGregor> | If Google+ breaks, that's a good PoC that some sites will break, subtly or not. |
| 17:17 | <AryehGregor> | I don't know if it's really such a problem, though, since it only affects UAs that *don't* implement the feature, and they can easily ship workarounds. |
| 17:18 | <AryehGregor> | othermaciej, well, that wasn't a case of *adding* a void element, it's a case of *changing* an element from void to non-void. I think that's an entirely different situation from what's being discussed. The processing of an *unrecognized* tag doesn't change much depending on whether it's void. |
| 17:19 | <AryehGregor> | Hixie, if you can persuade implementers, I say go ahead, but talk to the parser people at every browser and warn them that they should implement the parsing behavior ASAP even while they still process it as HTMLUnknownElement. |
| 17:19 | <othermaciej> | AryehGregor: Hixie is the one who cited <canvas> as a salient example |
| 17:20 | <AryehGregor> | Hixie, actually, one way to make the transition painless would be for browsers to deliberately support the parsing behavior for a while before they actually support the feature, so there's a window when authors will have no reason to bother using it (since it does nothing) but browsers won't break if they do. |
| 17:21 | <AryehGregor> | othermaciej, Hixie was talking about the initial support of <canvas> as a void element. That didn't cause any compat problems, right? It was the later change to a non-void element that caused the problems. |
| 17:22 | <othermaciej> | AryehGregor: I would say it was clearly the wrong choice to add it as void in retrospect, and that it wasn't non-problematic to do so |
| 17:22 | <othermaciej> | AryehGregor: it may have been a problem for totally different reason than <intent> could conceivably be |
| 17:22 | <othermaciej> | AryehGregor: but it's still not a good basis for arguing that it's fine to add void elements in general |
| 17:23 | <AryehGregor> | othermaciej, what problems did it cause to add it as void, other than the fact that it later deemed a good idea to make it non-void (which doesn't seem applicable here)? |
| 17:23 | <AryehGregor> | Well, if the argument is that new void elements in general are a problem, and <canvas> as a void element introduced no problems except ones that are clearly inapplicable to <intent>, I think it's fair to use it as an example. |
| 17:23 | <Hixie> | AryehGregor: certainly it's possible that i missed some stuff, but i did more than just look if the page seemed the same, i did try to use the page and test non-obvious things each time. this isn't my first barbecue. :-) |
| 17:24 | <othermaciej> | AryehGregor: I'm going to have to duck out of this discussion for now |
| 17:24 | <AryehGregor> | Hixie, you still didn't do anything that wouldn't have quickly shown up in even cursory testing. Because you were still only doing cursory testing. So disqualifying the Google+ breakage on the basis that it would have been caught by cursory testing still isn't sound. |
| 17:24 | <AryehGregor> | Really, we don't have to worry about sites like Google or Facebook, they'll do good enough testing. |
| 17:25 | <Hixie> | the Google+ breakage wouldn't have just been caught by cursory testing |
| 17:25 | <Hixie> | literally nothing rendered except a single triangle. |
| 17:26 | <AryehGregor> | GTG, but I think my point still stands. I think this is doable with a suitable dose of caution -- particularly, making sure that everyone lands the parsing changes ASAP, preferably some way before the feature is actually supported by any browser. |
| 17:35 | <tantek> | I find it odd that there's so much focus on the discovery of intent providers (ala <intent> element) rather than the far greater number of publishers who want to put various web action like buttons on their sites (without writing / copy/pasting a heap of JS). |
| 17:36 | <tantek> | In my web actions talk at OSBridge in June, I discussed the straw proposal of an <action> element provide publisher functionality, that is to invoke an action like share, save, post, favorite, follow etc. on the page. |
| 17:37 | <tantek> | http://tantek.com/presentations/2012/06/osb12-web-actions/#slide15 |
| 17:38 | <tantek> | start from the beginning if you want to see the context: http://tantek.com/presentations/2012/06/osb12-web-actions/ |
| 17:38 | <Hixie> | there's been a couple of proposals, e.g. using <form> |
| 17:38 | <tantek> | anyway, I see no reason to standardize "intents" until the proponents, e.g. Google, actually fix their existing functionality (e.g. G+ buttons) to be more state of the art like Twitter. |
| 17:39 | <Hixie> | o_O |
| 17:39 | <tantek> | until then, intents strikes me as overly complex technology designed by folks who aren't even shipping modern markup work arounds |
| 17:40 | <tantek> | way beyond the average web author |
| 17:40 | <tantek> | whereas the average web author has no problems implementing simple Tweet actions links - which work even without JS |
| 17:40 | <tantek> | (unlike the G+ buttons) |
| 17:42 | <tantek> | btw Hixie, speaking of overly complex, I've kept going over the use-cases an examples for the autocomplete stuff and am having trouble proposing anything substantially simpler :/ |
| 17:42 | <Hixie> | i hear ya |
| 17:42 | <Hixie> | i had the same problem |
| 17:42 | <tantek> | I may choose to take the path of not trying to match all the use-cases in preference for something simpler |
| 17:43 | <tantek> | that is, in basically saying, forget some of the whacky forms out there - those folks won't bother to update their markup with "autocomplete" attributes anyway |
| 17:43 | <Hixie> | unfortunately it's not clear that assumption is correct |
| 17:43 | <tantek> | I realize that involves making some judgment calls, but IIRC, you've in the past encouraged me to do so. |
| 17:43 | <tantek> | Hixie, usually inertia is a reasonable assumption :) (about people not updating their sites) |
| 17:43 | <Hixie> | oh, i absolutely agree that we have to make judgement calls about what to address and what not to address |
| 17:44 | <Hixie> | in this specific case, i think we're likely to see specific advocacy on adding those attributes |
| 17:44 | <tantek> | so I'm going to try to address a narrower subset to see if it generates a substantially simpler solution or not |
| 17:44 | <Hixie> | which makes it more likely that they'll get added |
| 17:44 | <Hixie> | especially if that advocacy comes with the promise of more sales |
| 17:44 | <Hixie> | which is plausible |
| 17:44 | <tantek> | sure, advocacy is something the a11y folks talk about too as a solution |
| 17:44 | <tantek> | that argument would also apply to fixing the forms themselves |
| 17:44 | <Hixie> | the accessibility folk can rarely point to concrete data showing improved conversion metrics in their advocacy :-) |
| 17:45 | <tantek> | so we if said, if you fix your forms and add these autocomplete attributes |
| 17:45 | <tantek> | that could work as well |
| 17:45 | <Hixie> | that typically also requires server-side changes |
| 17:45 | <tantek> | both do |
| 17:45 | <tantek> | though I think you mean data model / schema / database changes potentially |
| 17:45 | <tantek> | and yeah, that's a higher barrier, I agree |
| 17:46 | <Hixie> | right |
| 17:46 | <tantek> | anyway, just wanted to report back that I haven't been ignoring autocomplete, it's just been very frustrating :/ |
| 17:46 | <Hixie> | roger |
| 17:47 | <tantek> | if I had to choose between putting a complex solution or wait for some simplification, I'd probably choose the latter. |
| 17:47 | <tantek> | (into the spec) |
| 17:47 | <tantek> | but I suppose it's worth documenting as a discussion point at least |
| 17:48 | <Hixie> | i think the choice is more between putting a medium-complexity solution in, and being forced to put it in an even more complex one later by virtue of a browser and some extensions shipping support for a more complex proposal :-) |
| 17:48 | <tantek> | the complex version in there now feels like pretty bad feature bloat |
| 17:48 | <Hixie> | if you think what's in there now is complex, you should have seen some of the other proposals... :_P |
| 17:48 | <tantek> | and lots of headaches for browser vendors trying to fix bad use of a complex solution |
| 17:48 | <tantek> | yeah - I realize there were many worse |
| 17:48 | <Hixie> | well, the spec has a pretty solid processing model, i think |
| 17:49 | <tantek> | I'd expect as much |
| 17:49 | <Hixie> | insofar as it can for something so inherently heuristic based |
| 17:49 | <tantek> | the challenge is whether any authors can understand it well enough to get it right |
| 17:50 | <tantek> | anyway, those are just high level thoughts, not real objections. I'll speak up again on this when I've got more specific/concrete suggestions. |
| 17:50 | <tantek> | sorry that this feedback is not particularly useful at this point. |
| 17:51 | <Hixie> | no worries |
| 17:51 | <Hixie> | it will be very interesting to see what authors do with it |
| 17:51 | <tantek> | but in terms of specific feedback, I'd be interested in what you thought of using a new <action> element to wrap existing service-specific web actions, e.g. very roughly: |
| 17:51 | <tantek> | <action do="post" with="permalink"> |
| 17:51 | <tantek> | <a href=twitter>..</a> |
| 17:51 | Ms2ger | leaves Hixie to fix bugs |
| 17:51 | <tantek> | <a href=pinterest>...</a> |
| 17:51 | <tantek> | ... |
| 17:51 | <tantek> | </action> |
| 17:51 | <tantek> | no rush - just wanted to plant some more thoughts for consideration |
| 17:52 | <Hixie> | (i've been somewhat skeptical that anyone is going to use autocomplete, given the lack of success for past solutions, anyway. so it might end up entirely yanked at some point.) |
| 17:52 | <tantek> | for publishers who want to do both a generic web action, and have fallback to site-specific web actions |
| 17:52 | <tantek> | ah ok (re: autocomplete) |
| 17:53 | <Hixie> | tantek: for <action> i haven't studied the use cases enough to know what's needed and what's not |
| 17:53 | <tantek> | then I'll continue looking into simpler ways to markup such things - more from a copy/paste perspective (e.g. copy/pasting a whole contact, autocomplete is just a special case of that) |
| 17:53 | <Hixie> | tantek: (a lot of intents are actually a two-way conversation) |
| 17:53 | <tantek> | Hixie, hence <action> is just a rough sketch for now, based on existing publishing behaviors |
| 17:53 | <tantek> | the <a href> type actions, e.g. from Twitter, Pinterest, Foursquare etc. |
| 17:54 | <tantek> | (hopefully one day G+ will support <a href> actions instead of non-semantic JS-dependent <div> actions) |
| 17:54 | <Hixie> | it does seem like android has one action ("share") that is considered more important than others |
| 17:54 | <tantek> | Hixie, the simple intents that are actually in use on the web are mostly one-way conversations |
| 17:54 | <Hixie> | so maybe an <action> for that one intent makes sense |
| 17:54 | <tantek> | it might be a good starting point at least |
| 17:54 | <tantek> | and then we can iterate from there |
| 17:55 | <Hixie> | anyway, if you want this stuff considered, mail it on the thread :-) i don't have intents paged in right now |
| 17:55 | <tantek> | no problem |
| 17:55 | Hixie | has finally gotten around to dealing with bugs again, as Ms2ger noticed |
| 17:55 | <tantek> | I just saw the conversation above about it and was figuring I'd add a few opints. |
| 17:55 | <tantek> | points even. |
| 17:55 | tantek | wonders what an opint would be. a standard for Open Pints? |
| 17:57 | <hober> | iirc -o-pints are much more expensive than pints elsewhere in the world |
| 17:58 | <tantek> | hah |
| 17:59 | <astearns> | it's a measure of how long it takes to state your opinion. a tweet is 1opint |
| 18:00 | <Hixie> | man, the spec sure regenerates a lot faster now that i don't have to regenerate the w3c copy as well each time |
| 18:02 | <dglazkov> | Hixie: баба с возу, кобыле легче |
| 18:03 | <Hixie> | dglazkov: not how i would have put it, but yes |
| 18:04 | <dglazkov> | :) |
| 18:04 | <dglazkov> | I am just happy to apply some Russian wisdom to any situation, however appropriate. |
| 18:05 | <dglazkov> | Actually, "I am just happy" is probably enough, too. |
| 18:05 | <Hixie> | i wish there was a reliable way, in chrome, of starting a find-in-page at a specific place in a document |
| 18:06 | <dglazkov> | there's a special magic place to turn wishes into fishes: http://new.crbug.com/ :P |
| 18:06 | <Hixie> | i've had very little luck getting wishes turned into fish there |
| 18:07 | <dglazkov> | :-\ |
| 18:26 | <jamesr_> | dglazkov, "Woman with the cart, the mare is easier" ? |
| 18:28 | <dglazkov> | jamesr_: off the cart |
| 18:35 | <jgraham> | (fwiw the same kind of look-at-a-few-major-sites methodology would conclude that we didn't need the breaking-out-of-foreign-content-mode behaviour - which is hugely ugly and counterintuitive - because those huge sites don't typically have random <svg> tags in the source) |
| 18:38 | <jgraham> | (and if you think that frontend QA at Google or Facebook is good, I encourage you to look at https://github.com/operasoftware/browserjs/blob/master/desktop/browserjs-12.00.js ) |
| 18:39 | <jgraham> | (yes, some of those are working around real bugs in Opera. That isn't the point) |
| 20:18 | <hoolter> | is there any way to alter what the numbers say in <ol>s? like instead of "1.", "2.", "3.", i want to have "Item 1.", "Item 2.", and "Item 3."? |
| 20:41 | <espadrine> | I don't understand why what TabAtkins suggests doesn't work in strict mode, in this mail: <http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0394.html>; (it's the IndexedDB unprefixing thread) |
| 20:42 | <Ms2ger`> | indexedDB is a readonly attribute |
| 20:42 | <Ms2ger`> | That translates to a property without a setter |
| 20:42 | <Ms2ger`> | And in strict mode, assigning to such a property throws |
| 20:43 | <espadrine> | oh, readonly! |
| 20:43 | <espadrine> | ok, thanks! |
| 22:01 | <Hixie> | hoolter: in theory css lets you change it, dunno if anyone implements it |
| 22:19 | <hoolter> | Hixie: know how? |
| 22:19 | <gsnedders> | hoolter: Look up CSS counters |
| 22:20 | <hoolter> | gsnedders: are they widely implemented? |
| 22:20 | <gsnedders> | hoolter: Depends what you mean by widely. :) |
| 22:21 | <gsnedders> | They're in IE8 and everything else you'll care about. |
| 22:22 | <hoolter> | gsnedders: awesome! thanks :_ |
| 22:22 | <hoolter> | ) |
| 22:22 | <gsnedders> | Whether they work as expected on ol is a different question. :) |
| 22:23 | <hoolter> | gsnedders: why wouldn't they? |
| 22:24 | <gsnedders> | hoolter: You're assuming the numbering ol displays is implemented by CSS. :) |
| 22:25 | <hoolter> | gsnedders: i don't know what that sentence means. |
| 22:25 | <hoolter> | sorry :( |
| 22:25 | <gsnedders> | hoolter: ol shows numbering for the list. |
| 22:25 | <gsnedders> | That numbering may not be done using CSS. |
| 22:26 | <gsnedders> | If it is not, then you might not be able to override it using CSS. |
| 22:27 | <hoolter> | gsnedders: ah, i see. |
| 22:27 | <hoolter> | thanks. |
| 22:47 | <tobie> | jgraham: are you filing bug with us about those issues? |
| 22:49 | <gsnedders> | tobie: The ones which are patched through browser.js? |
| 22:50 | <gsnedders> | tobie: The ones that aren't Opera bugs have all been reported before being patched and gone unfixed for some period of time. |
| 22:50 | <gsnedders> | tobie: Some which are Opera bugs are never reported. |
| 22:52 | <Hixie> | well bummer |
| 22:52 | <Hixie> | per the spec, i think arguably <span><a></a></span> is non-conforming |
| 22:52 | <gsnedders> | wat. |
| 22:52 | <Hixie> | because the <a> doesn't contain phrasing content so it's not phrasing content... |
| 22:53 | <Hixie> | i wonder why <a> is only phrasing content when it contains phrasing content |
| 22:53 | <Hixie> | it doesn't need to be defined that way for the transparent content model thing to work |
| 22:55 | <tobie> | gsnedders: well LMK if there anything I can help with. I'm tobie⊙fc |
| 23:00 | <gsnedders> | tobie: In general most of our issues are down to conscious decisions not to support Opera, down to lack of marketshare, and a browser not supported by major sites won't get marketshare, etc. |
| 23:34 | <Hixie> | who should i cc on parser changes? jgraham, hsivonen, eseidel, abarth, anyone else? |
| 23:34 | <abarth> | fine with me |
| 23:35 | <abarth> | I can cc any other webkit folks as appriopriate |