| 00:00 | <jamesr> | how would you indicate the transition from initializing->normal? |
| 00:00 | <jamesr> | fire a context restored? |
| 00:00 | <zewt> | yeah |
| 00:00 | <zewt> | basically turning it into a readyState, i guess |
| 00:01 | <jamesr> | yeah. it might be a little awkward for developers to put their initial startup code in the contextrestored function |
| 00:02 | <Hixie> | are lost webgl contexts really that common? |
| 00:02 | <jamesr> | and in the lost handler they'd have to know if they were transitioning from init->lost (in which case they should show the webgl sadness) and normal->lost |
| 00:02 | <Hixie> | exposing this to web authors seems like a losing strategy. |
| 00:02 | <jamesr> | Hixie: on XP, every time the screensaver starts you lose context |
| 00:02 | <jamesr> | and every time the computer goes to sleep |
| 00:02 | <zewt> | Kenneth already described returning contexts in the "lost" state, which would require handling that too |
| 00:02 | <Hixie> | if UAs don't hide this from pages, they're just gonna break. |
| 00:02 | <jamesr> | and i believe you lost it when switching the logged in user on some OSes |
| 00:02 | <Hixie> | people aren't going to be testing this kind of thing. |
| 00:03 | <jamesr> | Hixie: yes. but UAs can't hide a webgl lost context from the page |
| 00:03 | <Hixie> | why not? |
| 00:03 | <jamesr> | how could you? |
| 00:03 | <jamesr> | to restore state, you'd have to save all commands + all resources for all commands and replay them from the beginning |
| 00:03 | <Hixie> | remember the state of the context and fake it |
| 00:03 | <zewt> | there are a lot more system-specifics for *GL than with most web APIs, that you can't avoid without crippling things |
| 00:03 | <jamesr> | the state of the context is potentially huge |
| 00:03 | <Hixie> | well i guarantee the web author ain't gonna do it |
| 00:03 | <jamesr> | it's the GL state and then all resources referenced from that state |
| 00:04 | <jamesr> | game authors sometimes do it properly |
| 00:04 | <Hixie> | not on the web |
| 00:04 | <zewt> | jamesr: if you're able to save state immediately before losing the context, you could serialize textures and so on; but I don't think you get any chance to do that with a lot of system 3D APIs |
| 00:04 | <jamesr> | but i agree that most won't |
| 00:04 | <Hixie> | if native app game authors only _sometimes_ do it properly, we're in for a world of pain here |
| 00:04 | <Hixie> | we can't ship an api this broken |
| 00:04 | <jamesr> | zewt: yeah you don't get any notification that the context is about to go away |
| 00:04 | <zewt> | webgl is already shipping :) |
| 00:04 | <jamesr> | Hixie: we did, heh |
| 00:04 | <jamesr> | thankfully nearly all XP users are currently blacklisted |
| 00:04 | <Hixie> | i predict doom for that api then |
| 00:05 | <Hixie> | mind you the ridiculous platform-specific-endianess thing pretty much already guaranteed doom too |
| 00:05 | <zewt> | i'm here late in the game but trying to do what little I can to reduce the chances of doom :) |
| 00:05 | Hixie | is unimpressed by webgl :-P |
| 00:05 | <jcranmer> | replace it with webmagic |
| 00:06 | <jcranmer> | which automatically figures out the right thing to do at every API invocation |
| 00:06 | <jcranmer> | and shoots the original developer if it can't |
| 00:06 | <jamesr> | webgl is definitely a different philosophy from most web apis |
| 00:07 | <zewt> | most web APIs aren't seriously hardware-bound, so they can get away with "make sure everyone can do the same thing"; if you did that with a 3d API you'd cripple it |
| 00:07 | <zewt> | that doesn't mean they shouldn't do everything they can to avoid accidentally tripping over that, though |
| 00:08 | <zewt> | for example, by making sure if you use any optional features, you explicitly enable them first |
| 00:08 | <zewt> | which they don't do at all |
| 00:08 | <jamesr> | they did for opengl extensions |
| 00:08 | <jamesr> | you have to turn them on and before you do they aren't available at all |
| 00:08 | <jamesr> | (shaders won't compile with them, etc) |
| 00:08 | <Hixie> | jamesr: yes, the different philosophy is the problem :-P |
| 00:08 | <zewt> | yeah but I'm talking about the basic stuff: MAX_TEXTURE_SIZE, etc |
| 00:09 | <jamesr> | ah yeah, they didn't define a required baseline for all of those |
| 00:09 | <jamesr> | i think the texture fetch count is a nastier one |
| 00:09 | <zewt> | i've already been bitten in the face by MAX_VERTEX_TEXTURE_IMAGE_UNITS, starting to implement something only to find that MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0 everywhere |
| 00:09 | <jamesr> | it's a number that you have to query. it's 0 most places |
| 00:09 | <jamesr> | heh yeah |
| 00:09 | <jamesr> | that one kind of blows |
| 00:10 | <zewt> | it's particularly nasty because the spec *specifically* says "everyone must support this"--but the "(but the max might be 0)" is implicit |
| 00:10 | <zewt> | great, everyone must support no fewer than 0 of something |
| 00:11 | <zewt> | there should be a table of minimums for every one of those variables, and you should have to explicitly set them higher if you want to use more |
| 00:11 | <zewt> | so at least if you're writing code that won't run everywhere, you know it |
| 00:12 | <zewt> | ... i'd suggest this on webgl-pub but it feels like too radical a change from webgl's design for it to even be worth suggesting |
| 00:21 | <zewt> | heh, i bet you could improve compatibility by always causing contexts to be lost if a tab is unfocused for more than a couple minutes--a lot more people would notice and implement webglcontextlost that way (unfortunately, it would also reduce net UA quality) |
| 00:34 | <Philip`> | zewt: Hmm, 0 everywhere? |
| 00:34 | <Philip`> | http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB seems to indicate it's typically non-zero |
| 00:34 | <Philip`> | at least in raw OpenGL |
| 00:35 | <zewt> | Philip`: https://groups.google.com/group/angleproject/browse_thread/thread/fbf08f0ab51ff26d |
| 00:36 | <zewt> | is the problem in practice |
| 00:37 | <Philip`> | Ah |
| 00:37 | <zewt> | it surprised me, since I'm sure my hardware supports it--if it was something advanced like trying to use 8 texture samplers I'd have checked earlier |
| 00:38 | <wilhelm> | Hixie: In chapter 7.5.2, "Custom scheme and content handlers", under the protocol argument, it says "Note: This feature is not intended to be used with non-standard protocols". What are non-standard protocols in this context? |
| 00:39 | <Hixie> | myprot: |
| 00:39 | <Hixie> | anything not registered with IANA |
| 00:39 | <wilhelm> | OK. So everything in the first table here, but nothing from the second? http://en.wikipedia.org/wiki/URI_scheme |
| 00:40 | <Hixie> | everything except those that are security issues like http: |
| 00:40 | <Hixie> | otherwise yes |
| 00:40 | <Hixie> | however, it is my belief that we should move away from IANA here |
| 00:40 | <Hixie> | and instead use something like wikipedia or some other wiki to register protocols |
| 00:40 | <Hixie> | which would make this mostly moot |
| 00:40 | <jamesr> | zewt: i think it's worth suggesting at least |
| 00:41 | <wilhelm> | Indeed. But then I presume we want a whitelist here. |
| 00:41 | <jamesr> | i'm not a true "webgl people" (have really no opengl background) but i'd like stuff to work |
| 00:42 | <zewt> | jamesr: i might, but will let the current stuff settle a bit |
| 00:42 | <Hixie> | wilhelm: why not a black list? |
| 00:42 | <jamesr> | earlier the better the odds of success are |
| 00:42 | <jamesr> | as more content gets out there it'll be harder to change |
| 00:42 | <Hixie> | wilhelm: i mean, in principle i agree that whitelists are better, but here you know what the dangerous ones are, they're the ones you implement. |
| 00:43 | <jcranmer> | Hixie: I can see some issues with blacklisting non-official URIs |
| 00:43 | <jcranmer> | particularly some well-known real-time-chat-related ones |
| 00:43 | <wilhelm> | That would allow the non-standard protocols – but that might not be a problem. |
| 00:43 | <Hixie> | what issues? |
| 00:43 | <jcranmer> | (aim, irc, skype) |
| 00:43 | <Hixie> | wilhelm: the UA should allow non-standard protocols |
| 00:43 | <wilhelm> | Noted. |
| 00:44 | <Hixie> | wilhelm: realistically, given how hard it is to register protocols, the majority of them will be unregistered. that's why i want to make it easier to register protocols. |
| 00:44 | <jcranmer> | I can imagine, e.g., a web-irc interface wanting to register IRC links |
| 00:44 | <Hixie> | that seems reasonable |
| 00:44 | <Hixie> | where's the problem? |
| 00:45 | <wilhelm> | If we have a blacklist of the scary stuff, there isn't one. (If we can make a definite list of scary stuff. :) |
| 00:45 | <jcranmer> | well, irc:// isn't a IANA-registered protocol, at least according to WP |
| 00:45 | <Hixie> | jcranmer: so? |
| 00:46 | <Hixie> | oh, i see what you're saying |
| 00:46 | <jcranmer> | well, if I didn't misread the earlier discussion |
| 00:46 | <Hixie> | i misunderstood, sorry |
| 00:46 | <jcranmer> | misunderstanding is very plausible |
| 00:46 | <Hixie> | agreed that we should not blacklist the unregistered ones (or whitelist the registered ones) |
| 00:46 | <jcranmer> | put another way |
| 00:46 | <Hixie> | only blacklist the ones the UA implements |
| 00:46 | <Hixie> | (and doesn't want to allow overriding of) |
| 00:46 | <jcranmer> | I expect that the primary use of registering oneself as a URI handler is will be to support uncommon protocols |
| 00:48 | <jcranmer> | mailto, news, nntp, and possibly tel or geo are the only official protocols on WP I can see someone feasibly wishing to handle |
| 00:49 | <jcranmer> | and even then, mailto is probably the only one which would see widespread adoption |
| 00:49 | <wilhelm> | Hixie: A related issue – should we aim for a blacklist or whitelist for the mimeType argument? Mozilla documentation indicates that they only whitelist a few types. (Our blacklist would have to be very long if we had one – there's plenty of MIME-types used internally that, if overruled, would break stuff fundamentally.) |
| 00:51 | <wilhelm> | jcranmer: Of those already supported by UAs? Probably. Stuff like spotify: (a vendor-specific scheme for a music streaming service) is very common in Europe, though. Although that might be intercepted at a different level. |
| 00:52 | <jcranmer> | my point is that I expect that the largest usage is going to be for unofficial ones |
| 00:52 | <wilhelm> | I wouldn't be surprised. |
| 00:53 | <jcranmer> | I might argue that most people aren't going to bother going through any registration process |
| 00:54 | <Lachy> | defining and registering a URI scheme is so unbelievably painful |
| 00:55 | <Lachy> | just look at the hassle I've been going through trying to get a spec written and approved by the IETF for the about: URI scheme |
| 00:55 | <jcranmer> | the most most people will go is plopping a brief syntax page on a blog |
| 00:55 | <jcranmer> | or perhaps a dedicated page squirreled away deep in the guts of some site somewhere |
| 00:56 | <Hixie> | wilhelm: the mime type list has to be a blacklist, the whole point is to allow arbitrary unknown (to us) types to be supported |
| 00:56 | <Hixie> | Lachy: yeah we really need to do something about that |
| 00:56 | <wilhelm> | Hixie: That makes sense. We'll just have to be very, very careful, then. |
| 00:56 | <Hixie> | wilhelm: yeah :-/ |
| 00:56 | <jcranmer> | I see what you mean about a mime-type blacklist |
| 00:57 | <jcranmer> | but, security wise, that makes you reactive instead of proactive |
| 00:58 | <Lachy> | Hixie, I'm working on it. Another editor volunteered to help with the spec, which encouraged me to actually spend some time on it |
| 00:59 | <Hixie> | AryehGregor: btw, the whatwg spec license isn't the MIT license, it's a custom license with much the same effects as MIT (but written less well) |
| 00:59 | <Lachy> | they actually tried to get the spec to require an IANA registry for about: URIs, to which I've said no |
| 00:59 | <Hixie> | Lachy: i meant fix the registry problem, not about: specifically, but glad to hear about: is moving forward |
| 01:00 | <Hixie> | AryehGregor: also, google doesn't own the copyright on the whatwg html spec, apple, mozilla, and opera do |
| 01:00 | <Hixie> | AryehGregor: the rest of your points stand though |
| 01:01 | <jcranmer> | Lachy: you put the about:mozilla easter egg in an RFC draft ‽ |
| 01:02 | <Lachy> | Hixie, why don't you get the WHATWG Members to agree to change the spec's licence to MIT, BSD or CC0? |
| 01:02 | <Lachy> | jcranmer, yes, as an example. Why? |
| 01:03 | <jcranmer> | it just seems... wrong |
| 01:03 | <Lachy> | why? |
| 01:03 | <wilhelm> | Hixie: And my third, and final question tonight – should there be any restrictions on the content in the title argument? Our prototype UI and prototype storage format aren't particularly happy about \n or very long strings, for example. (I suppose we're free to discard the parts of the string we don't like.) |
| 01:03 | <Lachy> | it's one of the most well known easter eggs, and is relevant to the draft. |
| 01:03 | wilhelm | notices “might use”. |
| 01:04 | <jcranmer> | I guess it seems to kind of defeat the purpose of easter eggs |
| 01:04 | <jcranmer> | I'm not exactly objecting to it |
| 01:04 | <Lachy> | wilhelm, just replace invalid characters with U+FFFD (Replacement Char) and Base64 encode the string. That should prevent any unwanted characters sneaking into the ini file |
| 01:05 | <Lachy> | jcranmer, oh, so you want it to remain a "secret" :-) |
| 01:05 | <wilhelm> | If we need to store that part at all… |
| 01:06 | <jcranmer> | well, an RFC ~= a specification, and mentioning easter eggs in specifications seems wrong |
| 01:06 | <jcranmer> | well, more objectionable than, say, putting it on Wikipedia |
| 01:09 | <Lachy> | btw, the latest editors' draft is here if you would like to review it. https://github.com/josephholsten/about-uri-scheme/raw/master/draft-holsten-about-uri-scheme-07.txt |
| 01:09 | <Lachy> | most significant changes are in section 5 |
| 01:09 | <Hixie> | Lachy: what problem would that solve, and is that problem costing more than it would cost me to try to herd the cats in question towards making a decision? :-) |
| 01:10 | <Hixie> | wilhelm: you can massage the string as you wish |
| 01:10 | <Hixie> | wilhelm: no restrictions in terms of throwing exceptions or whatnot as far as i recall, though |
| 01:10 | <Lachy> | Hixie, I'm not sure what you're referring to? |
| 01:11 | <Lachy> | oh, you mean the licence question? |
| 01:11 | <Hixie> | yeah |
| 01:11 | <Lachy> | (I forgot I asked) |
| 01:11 | <wilhelm> | Hixie: Got it. Thanks. |
| 01:11 | <Hixie> | Lachy: i shouldn'ta replied then :-P |
| 01:12 | <hober> | Lachy: what list do the about: discussions happen on? |
| 01:14 | <Lachy> | Hixie, it would make the licence consistent with that which we're asking the W3C to use, and by avoiding a custom licence, it reduces licence proliferation a little bit |
| 01:15 | <Lachy> | hober, unfortunately, all the comments I've received since the Last Call process began aren't being archvied. They're being CC'd just to the people involved with the discussion :-( |
| 01:16 | <Lachy> | I don't know why there is no mailing list. The draft-holsten-about-uri-scheme at tools.ietf.org address they're posting to doesn't seem to have an archive. |
| 01:16 | <wilhelm> | Hixie: (Stating clearly in the spec that arbitrary unknown URI schemes and MIME-types are to be supported might lessen the confusion for the next implementor that comes along. I voted in favour of a MIME type white list for our implementation earlier today, in fear of security implicatons. :) |
| 01:16 | <zewt> | is there any precedent (outside of WebGL) where merely registering an event handler (and not calling preventDefault from it) has side-effects? |
| 01:17 | <Hixie> | Lachy: yeah i don't think that benefit is worth it. But feel free to reach out to the charter members and try to convince them yourself if you think it is. :-) |
| 01:17 | <Hixie> | Lachy: i would certainly support your request |
| 01:17 | <Lachy> | Hixie, if the W3C did adopt MIT/BSD/CC0, would you think it's more worth making it consistent then? |
| 01:18 | <Hixie> | i would at least suggest it. it'd probably be easier to convince them in that kind of situation, too. |
| 01:18 | <Lachy> | ok |
| 01:18 | <Hixie> | wilhelm: can you file a bug or send mail on it? |
| 01:18 | <Hixie> | wilhelm: (feel free to use the bug reporting widget, that's sufficient) |
| 01:18 | <Hixie> | wilhelm: (and trivial) |
| 01:18 | <wilhelm> | Hixie: Sure. |
| 01:18 | <Hixie> | thanks |
| 01:19 | <zewt> | (webgl has side-effects from registering webglcontextrestored, which seems very weird; wondering if I'm able to say "nothing else anywhere does this") |
| 01:19 | <Hixie> | registering webglcontextrestored? |
| 01:20 | <Hixie> | you mean calling addEventListener()? |
| 01:20 | <Lachy> | zewt, what side effects? |
| 01:20 | <zewt> | webgl only automatically restores contexts if at least one webglcontextrestored event listener is registered |
| 01:20 | <Hixie> | that's totally bogus |
| 01:20 | <zewt> | that's the argument i'm about to make, i just want to double-check before I claim nothing else anywhere does it :) |
| 01:20 | <Lachy> | nothing else I'm aware of does that. |
| 01:33 | <Hixie> | wow |
| 01:33 | <Hixie> | the chairs don't think that "HTML is a media-independent semantic markup language" ??? |
| 01:33 | <jamesr> | what is it? |
| 01:34 | <Hixie> | they don't sa'y |
| 01:35 | <jamesr> | well i'm sure it is a useful and productive distinction |
| 01:36 | <jamesr> | zewt: if you don't have such an event listener registered is the behavior observable? |
| 01:36 | <jamesr> | zewt: if the context is restored but no JS runs then the context will still be just as dead as it was when it was still lost... |
| 01:41 | <zewt> | you can tell if a context is lost/restored without any events, using isContextLost (or just by calling any method; if the context is lost, nothing works) |
| 01:41 | <zewt> | eg. you could (as a dumb, contrived example) check for a lost or restored context in a timer |
| 01:42 | <zewt> | if you don't do canvas.addEventListener("webglcontextrestored", function(e) { }, false), it's never restored |
| 01:43 | <jamesr> | true. i think the thinking was that in general once the context is lost and restored you have to do a decent bit of work to try to reestablish the GL state before the context is useful at all |
| 01:43 | <jamesr> | so if a page isn't going to even attempt to restore context, there's not much point in doing work to try to restore it |
| 01:43 | <jamesr> | because the page is completely boned in the event of a lost context |
| 01:44 | <jamesr> | instead of depending on event registration maybe it should be an attribute on the context |
| 01:45 | <zewt> | i'm going to suggest that you have to preventDefault on webglcontextlost to indicate that you want it to be restored |
| 01:46 | <zewt> | eg. the default behavior of webglcontextlost is to prevent the context from being restored |
| 01:46 | <jamesr> | hm. might be a bit awkward for impls - you have to do some of C++ work to get the context restored before you can accept commands on it |
| 01:46 | <jamesr> | an |
| 01:46 | <jamesr> | ah wait, on loss |
| 01:46 | <jamesr> | not restore |
| 01:46 | <zewt> | all it is is a flag |
| 01:46 | <zewt> | right |
| 01:53 | <jamesr> | that'd be a breaking change for current content that correctly handles lost context |
| 01:53 | <jamesr> | (which is probably like 2 pages) |
| 01:53 | <jamesr> | but sounds reasonable i s'pose |
| 01:54 | <zewt> | if webgl guys are willing to change this stuff, i think it's worth it--everything related to events in webgl is sort of a mess |
| 01:55 | <zewt> | (if they're not, well, then they're not) |
| 07:05 | <hsivonen> | what version of the spec is generated with the "START epub" markers? |
| 07:10 | <othermaciej_> | a version published in epub format perhaps? |
| 07:12 | <hsivonen> | othermaciej_: the START epub directives affect what content is included |
| 07:12 | <othermaciej_> | it's a mystery to me |
| 07:12 | <hsivonen> | Hixie: X!<---->XX looks like a typo |
| 07:14 | <zewt> | i wonder how many people have mailed Edward so far with "please stop" |
| 08:28 | <Hixie> | hsivonen: nothing uses epub right now |
| 08:28 | <hsivonen> | Hixie: ok |
| 08:31 | <nessy> | Hixie, hsivonen: hmm… http://www.jedisaber.com/eBooks/Readers.asp |
| 08:34 | <Hixie> | hsivonen: fixed the typo, thanks |
| 14:46 | <AryehGregor> | Hixie, so when Google hired you to edit HTML5, they gave the copyright ownership away to Apple, Mozilla, and Opera? |
| 14:48 | <wilhelm> | AryehGregor: Not quite. Ian was an Opera employee editing the same spec initially. The copyright just never changed as he changed employers. (c: |
| 14:48 | <jgraham> | AryehGregor: Apple Mozilla and Opera already held the copyright. Presumably Google were happy for him to keep editing the document under those terms |
| 14:48 | <AryehGregor> | wilhelm, but legally, all the work he's done since he joined Google belongs to Google unless they explicitly transferred it in writing. |
| 14:49 | <wilhelm> | I'll leave it to the lawyers to determine how that works on a derivative work. (I have no idea. :) |
| 14:50 | <AryehGregor> | The general rule with derivative works is that the rights-holders to both the original work and the modifications have exclusive rights, which means you can't do anything with it (redistribute, etc.) without their joint permission. |
| 14:51 | <AryehGregor> | Or put another way, if you redistribute it etc. without permission, you infringe on the copyright of both parties. |
| 14:51 | <AryehGregor> | At least that's my understanding. |
| 14:52 | <gsnedders> | AryehGregor: Another question is whether Google owns all of Hixie's work or not |
| 14:52 | <AryehGregor> | gsnedders, why wouldn't they? He's a regular employee creating it as part of his job duties. |
| 14:53 | <AryehGregor> | Unless Google agreed otherwise in writing, they own the copyright to anything he creates as part of his duties as an employee. |
| 14:53 | <gsnedders> | AryehGregor: I don't know about US law. Certainly here, and I think everywhere in the EU, it has to be explicitly stated in the contract. |
| 14:53 | <AryehGregor> | (Whereas for instance, I'm a contractor, so Google only owns my job work because they stipulated that) |
| 14:54 | <gsnedders> | (Well, not in the contract, but somewhere where the author of the work has agreed to the transfer) |
| 14:57 | <AryehGregor> | gsnedders, for US law, see: http://en.wikipedia.org/wiki/Work_for_hire |
| 15:44 | <bga_> | [trolling] https://bugzilla.mozilla.org/show_bug.cgi?id=649408 |
| 16:11 | <AryehGregor> | You know, every time I see IE9 say "aryeh.name is not responding" and get annoyed because it actually means "IE is broken and can't run this webpage properly even though it works fine in every other browser", I realize that Windows application developers must feel exactly the same way about "foo.exe is not responding". |
| 16:12 | <AryehGregor> | "What do you mean, my program isn't responding? It's doing just fine, but your Win32 API call changed behavior between XP and Vista and so you made it go into an infinite loop!" |
| 16:13 | <hsivonen> | AryehGregor: you are having the Native experience! |
| 16:14 | <AryehGregor> | hsivonen, no, this is only IE9. |
| 16:14 | <AryehGregor> | I'd have to use IE10 if I wanted Native HTML5. |
| 16:14 | <hsivonen> | AryehGregor: oh. I see |
| 16:14 | <Philip`> | I thought IE9 was already native, and IE10 was more nativer |
| 16:15 | <Philip`> | (except IE10 on ARM which presumably isn't native) |
| 16:16 | <Philip`> | (unless you're allowed to port your application to multiple architectures with it still being native, you're just not allowed to port to any other OS) |
| 16:16 | <AryehGregor> | Oh, I see. |
| 16:17 | <AryehGregor> | My code was making the extremely silly assumption that if node.parentNode is not null, then node == node.parentNode.childNodes[i] for some i >= 0. |
| 16:17 | <AryehGregor> | Naturally, in Native HTML5 (or the precursor thereto) such naive assumptions do not hold. |
| 16:17 | <richardschwerdtf> | I would doubt Ian would allow Google to own what he has done, especially if he started the work prior to coming to google. |
| 16:18 | <AryehGregor> | So my code var ret = 0; while (node != node.parentNode.childNodes[ret]) ret++; has gotten up to ret == 2483917 in IE9. |
| 16:18 | <AryehGregor> | Well, at least there's a not-completely-horrible built-in debugger to let me figure this stuff out. |
| 16:18 | <AryehGregor> | richardschwerdtf, you mean you assume that Google would be willing to let him hold copyright to the work he does for them? |
| 16:19 | <Philip`> | Maybe it's actually in childNodes[2.5], wedged between two other nodes? |
| 16:19 | <Philip`> | Could be a performance optimisation to avoid having to shuffle the other nodes around when inserting new ones |
| 16:19 | <AryehGregor> | It's owned by Google unless they say otherwise, as long as he's their regular employee. |
| 16:19 | <AryehGregor> | Philip`, that's a very good idea. I'll be sure to check. |
| 16:19 | <richardschwerdtf> | No. I don't think Google paid attention to it. They are not like IBM or Apple |
| 16:19 | <Philip`> | Just enumerate all 64-bit floating point values |
| 16:20 | <richardschwerdtf> | or Microsoft |
| 16:20 | <bfrohs> | Philip`, well, any specs Ian works on only helps Google with every single web application they work on, so that would be a small price to pay to have progress being made in HTML |
| 16:20 | <zewt> | any competent company, large or small, pays attention to who owns the stuff they're paying people to make |
| 16:21 | <richardschwerdtf> | I think it depends on how you define competent. Google may find this completely acceptable. |
| 16:21 | <AryehGregor> | richardschwerdtf, 1) If they didn't pay attention to it, they own the copyright by default under US law. 2) It's universally accepted that software companies get the copyright to their employees' work; otherwise they couldn't function, unless they do only open-source stuff and never want to keep anything proprietary. 3) In my contract with Google, I was explicitly told that the copyright on all my specification work was to be held by Google. |
| 16:21 | Philip` | wonders if you could use typed arrays to implement float enumeration |
| 16:21 | <richardschwerdtf> | yes, but what if the work started prior to joining the company? |
| 16:21 | <Philip`> | (by incrementing the integer representation of a number, then reading back its float representation) |
| 16:21 | <AryehGregor> | They'd only hold copyright to the things he did on company time, obviously. |
| 16:22 | <richardschwerdtf> | from what I have seen of Ian I would think he would want to be able to control his work on HTML whether he were working at Google or not |
| 16:22 | <zewt> | AryehGregor: (rather, "while employed at Google"; it doesn't generally matter to work-for-hire whether you're doing stuff on company time or not) |
| 16:23 | <gsnedders> | AryehGregor: I had gotten the impresssion it wasn't unusual in the US for software companies to own all code written by employees, regardless of whether for work or not |
| 16:23 | <AryehGregor> | zewt, sure it does. If you're not doing it as part of your duties as an employee of the company, they don't hold the copyright. If I write a novel in my spare time, my employer doesn't get the copyright. |
| 16:23 | <richardschwerdtf> | Imagine, you have a falling out. with your employer on HTML and wanted to continue to edit the spec. elsewhere. |
| 16:24 | <AryehGregor> | richardschwerdtf, also, you know, the specification says that the copyright is held by Apple, Mozilla, and Opera. And Ian himself said that in this channel just today. |
| 16:24 | <AryehGregor> | So, you know, this isn't really a case where we need to do personality analysis on anyone. |
| 16:24 | <zewt> | AryehGregor: if they're paying him to work on specs, then this is work on specs; a major point of the concept of "work for hire" is making it so people can't be paid to create something, then claim after the fact that they did it on their own time |
| 16:24 | <richardschwerdtf> | I am sure Google and Microsoft would just love their omission |
| 16:24 | <jgraham> | It is not beyond the realm of possibility that Hixie insisted on this as a clause in his contract |
| 16:24 | <AryehGregor> | A "work made for hire" is— (1) a work prepared by an employee within the scope of his or her employment; or (2) a work specially ordered or commissioned for use as a contribution to a collective work, as a part of a motion picture or other audiovisual work, as a translation, as a supplementary work, as a compilation, as an instructional text, as a test, as answer material for a test, or as an atlas, if the parties expressly agree in a writt |
| 16:24 | <AryehGregor> | en instrument signed by them that the work shall be considered a work made for hire. (17 U.S.C. § 101) |
| 16:25 | <AryehGregor> | "within the scope of his or her employment" |
| 16:25 | <AryehGregor> | jgraham, and then he still left the spec saying that it's copyrighted by Apple, Mozilla, and Opera? |
| 16:25 | <AryehGregor> | (and the W3C) |
| 16:25 | <AryehGregor> | (for the W3C version) |
| 16:25 | <Philip`> | AryehGregor: From what I've heard it's common for employment contracts to say they own all software you write even if it's on your own time, and you have to negotiate exceptions if you want to do things that won't compete with the employer |
| 16:25 | <zewt> | right, which means "the stuff you do for your company" (eg. "write specs"), not "stuff you do 9-5 while in the office" |
| 16:25 | <richardschwerdtf> | yes. like I said I am sure Ian covered his bases. |
| 16:25 | <AryehGregor> | (I don't get how multiple parties are independently claiming they hold the copyright) |
| 16:26 | <jcranmer> | release it public domain! |
| 16:26 | <AryehGregor> | Philip`, I wouldn't be surprised if some contracts stipulated that, yeah. |
| 16:26 | <jcranmer> | ;-) |
| 16:26 | <jgraham> | I mean insisted that work on HTML5 get realeased under the existing copyright terms |
| 16:26 | <jgraham> | But I don't really know anything about this stuff |
| 16:26 | <zewt> | (FWIW, I don't really think there's any problem here--I have no concerns about Google playing contract games to try to usurp the HTML spec copyright--so in my opinion this is all academic) |
| 16:26 | <AryehGregor> | richardschwerdtf, okay, have you noticed where the spec says "© Copyright 2004-2011 Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA."? Could you please explain this text according to the theory that Ian holds the copyright on his own work? |
| 16:27 | <AryehGregor> | It's academic in the case of HTML. The spec is released under a permissive license anyway. |
| 16:27 | <AryehGregor> | It doesn't matter who owns it. The only benefit the owner gets is they don't have to give attribution to themselves, or whatever. |
| 16:27 | <jgraham> | AryehGregor: Doesn't W3C claim copyright on the W3C spec? I don't see how either is compatible with the idea that Google (or Hixie) holds copyright on Hixie's contributions |
| 16:28 | <AryehGregor> | jgraham, yeah, I'm confused by that. |
| 16:28 | <richardschwerdtf> | @AryeGregor: I saw that. Ian has claimed he owns copyright on W3C forums if I recall |
| 16:28 | <Philip`> | Surely Google's evil plan is to wait until Microsoft fully implements Native HTML5 and then reveal that actually they have copyright ownership over all of HTML5 due to some technicality and then sue Microsoft for billions of dollars |
| 16:28 | <richardschwerdtf> | Google is not on the copyright list |
| 16:28 | <Philip`> | That's the only reason they're funding this work on HTML5 at all |
| 16:28 | <Philip`> | richardschwerdtf: That's how cunningly they're hiding their conspiracy |
| 16:29 | <AryehGregor> | richardschwerdtf, so on the one hand we have your recollection. On the other hand we have the text in the actual spec (which Ian wrote), plus also: [110412 20:05:24] <Hixie> AryehGregor: also, google doesn't own the copyright on the whatwg html spec, apple, mozilla, and opera do |
| 16:29 | <jgraham> | Philip`: If it were Oracle… |
| 16:29 | <AryehGregor> | That was barely more than twelve hours ago. |
| 16:29 | <richardschwerdtf> | so, who owns copyright on the WhatWG spec? |
| 16:29 | <AryehGregor> | . . . |
| 16:29 | <AryehGregor> | Okay, seriously, what? |
| 16:31 | <richardschwerdtf> | so, everyone but google has copyright on the spec. hmmm. sounds like they don't have rights to it |
| 16:31 | <AryehGregor> | It's permissively licensed. |
| 16:32 | <AryehGregor> | Anyone can use it however they want. |
| 16:32 | <richardschwerdtf> | people can create derivative works |
| 16:32 | <jgraham> | Right, afaict the only rights the copyright holders have is to change the license for future revisions |
| 16:32 | <AryehGregor> | Also, looks like Windows 7 hasn't gotten rid of that "If you don't say otherwise within ten minutes I'm going to restart the computer and destroy all your work" feature. |
| 16:32 | <AryehGregor> | Go Microsoft. |
| 16:32 | <richardschwerdtf> | do the derivative works have to have apple, mozilla, and opera copyright transferal? |
| 16:32 | <Philip`> | AryehGregor: It's for your own good |
| 16:33 | <zewt> | hey, they need to install those updates to prevent data loss |
| 16:33 | <richardschwerdtf> | I am not sure how that works? |
| 16:33 | <TabAtkins> | AryehGregor: On my comp, at least, W7 doesnt' auto-restart. It just throws up a prompt that is content to wait around forever. |
| 16:33 | <AryehGregor> | richardschwerdtf, no. It's a permissive license. You can do anything you want with derivative works as long as you give attribution. |
| 16:33 | <AryehGregor> | TabAtkins, I just saw one with a countdown. |
| 16:33 | <richardschwerdtf> | interesting |
| 16:33 | <richardschwerdtf> | So, w3c could do that |
| 16:34 | <zewt> | my favorite is if csrss crashes in XP, and it pops up a dialog saying "error, rebooting in 30 seconds" |
| 16:34 | <zewt> | and there's *no way* to say "hold on give me a second here" |
| 16:34 | <zewt> | (yeah, csrss crashing is *bad*, but come on) |
| 16:34 | <AryehGregor> | Oh, now my code is just crashing the tab in IE instead of looping infinitely. That's progress. |
| 16:35 | <AryehGregor> | Seriously, what the heck is so broken with IE here? |
| 16:36 | <jgraham> | csrss? |
| 16:36 | <AryehGregor> | I guess it's to Microsoft's credit that I even ask the question. In IE before IE9, it wouldn't have even occurred to me to be surprised. |
| 16:36 | <zewt> | system service process |
| 16:36 | <jgraham> | richardschwerdtf: Sure, W3C could fork HTML5 is they want |
| 16:37 | <richardschwerdtf> | ok |
| 16:37 | <jgraham> | I mean they already have one copy with their copyright that is different to the W3C copy so they wouldn't even rely on the WHATWG license |
| 16:38 | <richardschwerdtf> | Interesting |
| 16:39 | <jgraham> | But if the plan was "fork and change the editor" I expect there would be significant difficulty in getting people to pay attention to the fork |
| 16:39 | <hsivonen> | jgraham: look for "non-exclusive" in http://lists.w3.org/Archives/Public/public-html/2007Apr/0429.html |
| 16:39 | <bfrohs> | Aye, especially with three browser vendors backing the WHATWG version, and the editor being from the fourth vendor :P |
| 16:40 | <jgraham> | hsivonen: I still don't really understand |
| 16:46 | jgraham | worries that he is not sufficiently grown up to have a proper conversation on, well pretty much any subject at all, given how amused he is by the headline "Soap giants in price fixing fine" |
| 16:46 | <jgraham> | I mean it's not even very funny |
| 16:46 | <TabAtkins> | It is acceptable for people of any age to be amused by headline-ese. |
| 16:49 | <zewt> | of course, today we have bad URL snippet generators, leading to such interesting things as "banksy-billboard-cbs-the-light-group-academy-awards-graffitti-bomb-sunset-gas-station-norm-76-mickey-mouse-minnie-mouse-las-vegas" |
| 17:55 | <hsivonen> | for native HTML5: https://bug649408.bugzilla.mozilla.org/attachment.cgi?id=525702 |
| 18:09 | bfrohs | really hates that file inputs aren't styleable |
| 18:10 | <zewt> | ff4/chrome's HTMLInputElement.click fixes that, though |
| 18:11 | <zewt> | except i havn't been able to figure out a way to feature test that... |
| 18:12 | <bfrohs> | Not sure I would call that a 'fix' :P |
| 18:13 | <AryehGregor> | What's wrong with: "click" in document.createElement("input") |
| 18:13 | <zewt> | the method exists in browsers where it doesn't do anything, iirc |
| 18:14 | <AryehGregor> | Obnoxious. |
| 18:14 | <bfrohs> | and the fact that you have to use javascript to use an 'official' hack to get around the style issue... which has always been possible with label. |
| 18:14 | <zewt> | well, styling for file inputs varies a lot, too |
| 18:16 | <bfrohs> | input[type="file"]:button and input[type="file"]:input (or equiv) would be a beautiful thing |
| 18:17 | <zewt> | yeah, but in practice with so many browsers having hideous file widgets (FF's is *really* bad) usually I'd sooner just make my own button |
| 18:18 | <zewt> | but sure, would be nice to have some control over that |
| 18:18 | <bfrohs> | Yeah, but at least some day things would be easy |
| 19:48 | <Rik`> | hsivonen: the new Perian version provides Quicktime components for WebM |
| 19:48 | <Rik`> | sadly, looks like Safari is not using them |
| 19:51 | <Rik`> | maybe I need to restart for Safari to discover those new Quicktime components |
| 20:04 | <eric_carlson> | Rik`: file a bug if Safari doesn't use installed QuickTime component - problems are much more likely to be fixed if you tell someone about them |
| 20:05 | <Rik`> | eric_carlson: that's what a Perian guy told me on twitter |
| 20:05 | <Rik`> | I just can't reboot right now |
| 20:06 | <eric_carlson> | Rik`: OK. Can you cc me if you do write up a bug? |
| 20:08 | <Rik`> | eric_carlson: in the perian bug tracker or radar ? |
| 20:08 | <eric_carlson> | Rik`: webkit bug and/or Radar |
| 20:09 | <eric_carlson> | Rik`: eric.carlson⊙ac |
| 20:16 | <TabAtkins> | Every song by The Ink Spots reuses the same opening, as far as I can tell. |
| 20:16 | TabAtkins | is running a 50's jazz/r&b station on pandora. |
| 20:19 | <yijun> | hello, there |
| 21:27 | <zewt> | Hixie: re: exposing blacklisted WebGL by treating it as not a supported contextId; it may work for them, but they need a way to give an error message to the application (eg. "Blacklisted video card" or "WebGL not supported in Windows 3.1"); could use any thoughts of how to do that with getContext |
| 22:18 | <Hixie> | zewt: just have the UA tell the user, why does the page need to know? |
| 22:18 | <Hixie> | zewt: it would be bad to tell the page too much information, hostile pages could then use it to know what kind of attack to try |
| 22:22 | <zewt> | i'll pass that along, though there are probably cases where you'd prefer the page not say anything to the user, so you can fall back to another method cleanly |
| 22:22 | <zewt> | but I guess if that's wanted it can just be a getContext parameter |
| 22:32 | <zewt> | though, WebGL specifying that canvas.getContext("webgl", {silentFailures: true}); prevents those notifications is hairy, since that would require their spec monkey-patch getContext's spec--not nice |
| 22:33 | <zewt> | (for example, if you're only opening webgl to run some kind of feature detection, you probably don't want the UI notifying the user if it fails) |
| 22:37 | <jamesr> | economist.com attempts (or used to attempt) to initialize a webgl context as some sort of feature detection |
| 22:37 | <jamesr> | and then doesn't use the context ever |
| 22:37 | <jamesr> | they are/were using some sort of fallback library that offered to feature test a bajillion things and then put the results into a big dictionary |
| 22:38 | <jamesr> | and they asked it to check webgl |
| 22:38 | <zewt> | that seems reasonable--not ideal, since in principle each webgl context could have different features, but shouldn't pop up ui |
| 22:38 | <jamesr> | i think they set the library up to feature test everything it was capable of, but then never actually checked 99% of the features they testd for |
| 22:39 | <zewt> | (contrived example, gpu blacklisting might also restrict a certain GPU to 2 texture units to work around driver bugs) |
| 22:40 | <jamesr> | it's not super reasonable because the page didn't use webgl in any way |
| 22:40 | <jamesr> | so the page load got a lot slower if the browser supported webgl (context initialization is not cheap) for no user benefit |
| 22:40 | <zewt> | right, it's not an ideal thing for pages to do |
| 22:44 | <Hixie> | context initialization shouldn't be sync anyway |
| 22:44 | <jamesr> | indeed |
| 22:45 | <zewt> | well, the "simplest" solution to all this would be to make getContext return a tiny factory with its own API for creating the real WebGL context |
| 22:45 | <zewt> | that'd be totally incompatible, though |
| 22:45 | <Hixie> | that would be lame |
| 22:46 | <zewt> | why? there's no async version of getContext |
| 22:46 | <zewt> | unless you want to add one, heh |
| 22:46 | <jamesr> | i think it'd be easier for getContext("webgl") to return a context in the 'initializing' state and then fire an event when the context is ready to go |
| 22:46 | <Hixie> | right |
| 22:46 | <Hixie> | though frankly i'm not convinced we should be exposing the slowness of the hardware to js at all |
| 22:47 | <jamesr> | canvas.addEventListener("webglcontextready", domyshit); canvas.getContext("webgl", {async: true}); |
| 22:47 | <Hixie> | but that gets back to the thing about how maybe webgl is the wrong approach entirely, and that's not a battle i have the bandwidth for :-) |
| 22:47 | <Hixie> | {async:true} should be the default and only option |
| 22:47 | <Hixie> | c.f. XHR |
| 22:47 | <jamesr> | yeah |
| 22:48 | <jamesr> | i think the same is true for readPixels(), getIntegerv(), etc - all the long blocking calls |
| 22:49 | <jamesr> | but i haven't though that through fully |
| 22:49 | <jamesr> | been thinking about it with regards to that slow shader compilation thread |
| 22:49 | <zewt> | well, the same can happen with 2d canvases: since a complete <img> may not actually be decompressed, blitting an image to a canvas may take a long time (which has to be sync, at least if you eg. make a call to getImageData immediately after) |
| 22:50 | <zewt> | (browsers like to discard undisplayed images to save memory) |
| 22:50 | <Hixie> | drawImage() does nothing if the image isn't ready |
| 22:50 | <Hixie> | it doesn't block |
| 22:51 | <zewt> | the image is ready, it's just not decompressed in memory; as soon as you do anything with it, the browser decompresses it |
| 22:51 | <Hixie> | but yes, the 2d context is sync in many places, that's an unfortunate bug we haven't been able to fix |
| 22:51 | <Hixie> | it was inherited from apple's initial implementation |
| 22:51 | <zewt> | webgl inherits from opengl; everyone has their legacy, I guess :) |
| 22:54 | <jamesr> | we can't do much about 2d canvas at this point |
| 22:54 | <jamesr> | despite it being kind of bad in many places |
| 22:54 | <jamesr> | hopefully we can still fix webgl issues |
| 22:55 | <Hixie> | indeed |
| 22:55 | <zewt> | do you have any sense of whether there's any chance of making getContext async by default? it would be a totally breaking change, so I'd imagine not, but I don't know their compatibility philosophy at this stage |
| 22:55 | <zewt> | (if I were them, I'd say no, since losing momentum on people who have started using webgl already would be a hit for them) |
| 22:56 | <Hixie> | depends what you mean by async |
| 22:56 | <zewt> | <jamesr> canvas.addEventListener("webglcontextready", domyshit); canvas.getContext("webgl", {async: true}); |
| 22:56 | <Hixie> | i don't think we should do that |
| 22:56 | <Hixie> | i think we should just return an object that's initialising |
| 22:56 | <jamesr> | in that proposal it returns an object immediately |
| 22:56 | <jamesr> | right |
| 22:56 | <zewt> | how's that different from the above? |
| 22:56 | <jamesr> | and the webglcontextready tells you when the context is ready to receive draw commands |
| 22:56 | <jamesr> | you basically said what i said :) |
| 22:57 | <Hixie> | and it should act as if it was initialised until such time as the page does something that can tell if it really was initialised or not |
| 22:57 | <Hixie> | at which point it blocks |
| 22:57 | <zewt> | hmm |
| 22:57 | <jamesr> | if you issued draw calls on the context before it was ready you'd get an immediate exception |
| 22:57 | <Hixie> | much like how things like .offsetWidth and CSS work |
| 22:57 | <jamesr> | just like how lost contexts behave |
| 22:57 | <jamesr> | no, i don't think the implicit blocking is good |
| 22:57 | <Hixie> | jamesr: i don't think that's a good design either |
| 22:57 | <jamesr> | .offsetWidth's behavior is terrible for applications |
| 22:57 | <Hixie> | contexts should always work, imho |
| 22:58 | <jamesr> | it causes impossible to diagnose performance issues |
| 22:58 | <zewt> | jamesr: an advantage of implicit blocking is it's backwards-compatible, though |
| 22:58 | <Hixie> | imho we shouldn't expose hardware and OS limitations |
| 22:58 | <Hixie> | anyway |
| 22:58 | <Hixie> | not my problem :-P |
| 22:58 | <jamesr> | a disadvantage of implicit blocking is that it's terrible and slow |
| 22:58 | <Hixie> | i have enough problems to deal with as it is :-P |
| 23:01 | <zewt> | trying to only bug you where the problems intersect with getContext :P |
| 23:01 | <jamesr> | so i think getContext should return something immediately |
| 23:01 | <jamesr> | a |
| 23:01 | <jamesr> | and it should be up to WebGL to define how interactions with that context work |
| 23:03 | <zewt> | jamesr: the options at that point are 1: block when needed (ugly but backwards-compatible), 2: *always* return an initializing canvas, and queue an event to initialize it, so it's *guaranteed* that you can never use the context until webglcontextrestored (or whatever) is fired async |
| 23:03 | <jamesr> | {async: true} can be an indication to webgl that the context should start uninitialized and that it should fire an event when the context is ready to go, or another event if the context is never gonna come up |
| 23:03 | <jamesr> | zewt: yeah i prefer 2 |
| 23:03 | <zewt> | that is, even if the browser is able to return an already-initialized canvas, it must not |
| 23:04 | <jamesr> | well, only if it's the first call |
| 23:04 | <zewt> | right |
| 23:04 | <zewt> | (err, already-initialized context) |
| 23:04 | <jamesr> | subsequent calls get the primary context in whatever state its in |
| 23:04 | <jamesr> | so maybe they get a still-uninitialized context, maybe they get an initialized context, maybe they get a lost context |
| 23:04 | <jamesr> | but the first call creates and immediately returns an uninitialized context |
| 23:09 | <Hixie> | are any of the pro-<u> people who actually want <u> for semantic reasons and not presentational reasons here by any chance? (or are there no such people?) |
| 23:10 | <AryehGregor> | I think there are a couple of Chinese people who want it for semantic reasons. |
| 23:10 | <AryehGregor> | I'm pretty sure most of us want it for presentational reasons, though. |
| 23:10 | <Hixie> | i'm trying to apply this <u> CP but the semantic definition in the CP makes no sense (it mixes multiple unrelated things together) |
| 23:10 | <AryehGregor> | Hixie, I managed to work into the change details that it's just an example and you can make more or less whatever change you like as long as it makes <u> conforming. |
| 23:11 | <Hixie> | i guess i could just have it be defined as "the one presentational element in the language" |
| 23:11 | <Hixie> | but i can't really see why we would want to add presentational elements |
| 23:11 | <AryehGregor> | Or redefine <b> and <i> and <sup> and <sub> and . . . as presentational. :) |
| 23:11 | <Hixie> | that would be a retrograde step |
| 23:11 | <AryehGregor> | I'm aware you think that. :) |
| 23:12 | <Hixie> | i really don't understand this concept of wanting HTML to have presentational markup |
| 23:12 | <Hixie> | but anyway |
| 23:13 | Hixie | looks at the Decision to see if any sort of rationale can be determined from that |
| 23:13 | <Hixie> | it looks like the main rationale is "wysiwyg tools output it" |
| 23:13 | <Hixie> | so maybe that would be the definiton to use |
| 23:14 | <Hixie> | "represents text that was underlined in a WYSIWYG tool" |
| 23:14 | <othermaciej> | you could just start with the B definition: "The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is boldened." |
| 23:14 | <othermaciej> | and replace the "such as" list |
| 23:14 | <othermaciej> | and the word "boldened" with "underlined" |
| 23:14 | <Hixie> | if <b> and <u> both have the same meaning, we should drop one of them. |
| 23:15 | <Hixie> | the normative part of the <b> definition is "a span of text to be stylistically offset from the normal prose without conveying any extra importance" |
| 23:15 | <Hixie> | it doesn't mention bold at all except in the non-normative list of examples |
| 23:15 | <othermaciej> | the <i> definition (skipping the "such as") is "The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose" |
| 23:15 | <kennyluck> | then what about "a span of text to be stylistically offset from the normal prose without conveying any document edit" |
| 23:16 | <othermaciej> | which seems like a superset of "stylistically offset from the normal props without conveying extra importance" |
| 23:16 | <Hixie> | othermaciej: right, supersets are common in HTML. e.g. <span> is a superset of all the phrasing elements. |
| 23:16 | <othermaciej> | so the spec already allows multiple different elements for different kinds of text stylistically offset from the normal prose |
| 23:17 | <othermaciej> | it seems like the only difference between b and i is that i may (but does not have to) indicate extra importance |
| 23:17 | <othermaciej> | though none of the listed examples indicate extra importance afaict |
| 23:17 | <Hixie> | i is a non-stylistic offset |
| 23:17 | <Hixie> | b is a stylistic offset |
| 23:18 | <Hixie> | the examples demonstrate this quite well, i think |
| 23:18 | <Hixie> | e.g. reading the <i> examples, they are all cases where you'd speak with a different voice (typically slightly slower), whereas the <b> examples you wouldn't read differently at all |
| 23:19 | <othermaciej> | so the key difference is whether the offset is stylistic? |
| 23:19 | <kennyluck> | Hixie, I don't agree with that, especially when <i> is used for technical terms. |
| 23:19 | <othermaciej> | you'd speak a ship name or taxonomic name in a different voice? |
| 23:19 | <Hixie> | right. <b> has more in common with <mark>: one is key words or passages that the author highlights, while the second is key words or passages highlighted by an editor. |
| 23:19 | <othermaciej> | I certainly haven't noticed sea captains or biologists doing that in speech |
| 23:20 | <AryehGregor> | I don't speak ship names or taxonomic terms in a different voice. |
| 23:20 | <AryehGregor> | Or loanwords, even if I'd italicize the loanword. |
| 23:20 | <gsnedders> | I do! |
| 23:20 | <Hixie> | othermaciej: for ship names and species names there's a pause before the name (same as book names with <cite>, actually). |
| 23:20 | <gsnedders> | I make them sound all impressive and stuff! |
| 23:20 | <othermaciej> | English typographic rules are unfortunately slightly ad-hoc |
| 23:20 | <othermaciej> | Hixie: you have unusual prosody, then |
| 23:20 | <Hixie> | that's possible |
| 23:21 | <othermaciej> | "The scientific name for the common house cat is <i>felix catus</i>." |
| 23:21 | <othermaciej> | er, "felis catus" |
| 23:21 | <othermaciej> | anyway |
| 23:21 | <othermaciej> | most people would not pause in that sentence, unless they were unfamiliar with the term, in which case it is a matter of confusion, not style |
| 23:21 | <Hixie> | i definitely speak that "felis catus" part differently. |
| 23:22 | <AryehGregor> | I'd say it differently in that specific sentence. |
| 23:22 | <AryehGregor> | But not because it's a taxonomic term. |
| 23:23 | <AryehGregor> | If I said "The common term for the United States is 'America'", I'd also pronounce "America" differently. |
| 23:23 | <Hixie> | yeah, quotes are similar in style |
| 23:23 | <AryehGregor> | Although actually, properly speaking, "America" should probably be italicized there. |
| 23:23 | <othermaciej> | because it's a copula? |
| 23:23 | <AryehGregor> | I dunno. |
| 23:24 | <AryehGregor> | What I'm very sure of is that the rules for italics in English are not tied to pronunciation, they're tied to various historical conventions that developed solely in writing. |
| 23:24 | <Hixie> | another way of thinking of the difference between <i> and <b> is that <i> is something that applies to the text, such that if you copied the sentence to another document you'd keep the same <i>s, whereas <b> is context-sensitive, so you might not keep the same <b>s and might in fact have different <b>s |
| 23:24 | <othermaciej> | "The frequency of red light is about 680 nanometers" |
| 23:24 | <AryehGregor> | My copy of Paradise Lost has all proper nouns italicized. Does anyone pronounce all proper nouns differently from other words? |
| 23:24 | <Hixie> | that wouldn't be <i> imho |
| 23:24 | <Hixie> | more <b> |
| 23:25 | <Hixie> | (but that's splitting hairs) |
| 23:25 | <othermaciej> | so the quasi-semantic uses of <u> sound similar to <i>, except that there is a different ad-hoc list of things where the relevant default typographical rule applies |
| 23:25 | <Hixie> | well the key difference is that the uses for <u> are virtually non-existent in comparison |
| 23:26 | <AryehGregor> | You realize that no one but you is actually going to consistently use <b> and <i> for the semantics you've defined, right? Everyone's just going to use them for bold and italics. |
| 23:26 | <AryehGregor> | Even standards aficionados. |
| 23:26 | <AryehGregor> | I'm not sure anyone but you actually understands the semantics you've defined for <b> or <i>. |
| 23:26 | <TabAtkins> | Hey, I used <i> for the correct purpose! (Actually, fantasai corrected me and made me use <i>.) |
| 23:26 | <Hixie> | nobody uses <cite> consistently either, doesn't mean there's no benefit to having clear definitions |
| 23:27 | <othermaciej> | in practice, <i> <b> and <u> will be inserted when the user of a WYSIWYG editor hits Cmd+I, Cmd+B or Cmd+U respectively |
| 23:27 | <Hixie> | what will be inserted when the user in a WYSIWYG editor drags an image to a specific position on the page? |
| 23:28 | <othermaciej> | <img>? |
| 23:28 | <Hixie> | what if the position is over another image? |
| 23:28 | <AryehGregor> | What does "over another image" mean? |
| 23:28 | <TabAtkins> | <img> with abspos? |
| 23:28 | <AryehGregor> | It will be inserted at wherever you drag it to. |
| 23:28 | <Hixie> | why don't we have html elements for abspos then? |
| 23:28 | <AryehGregor> | Probably it'll go before or after the existing one. |
| 23:28 | <othermaciej> | I haven't tested WYSIWYG editors that allow exact positioning control to see what they do |
| 23:29 | <AryehGregor> | Pretty sure it's not gonna be absolutely positioned. |
| 23:29 | <TabAtkins> | Because Aryeh isn't speccing something that requires absposing stuff? |
| 23:29 | <AryehGregor> | I'm currently speccing what browsers implement, or some approximation thereto. |
| 23:29 | <AryehGregor> | And they don't implement any such thing. |
| 23:29 | <othermaciej> | even though people think of bold, italic and underline presentationally, they often affect the meaning of the text in some way (even if not clearly expressed or even understood by the user) |
| 23:29 | <AryehGregor> | Generally, contenteditable stuff is meant to be sliced out and reused in other pages, so abspos wouldn't make sense unless you could guarantee the position relative to some non-statically-positioned container. |
| 23:30 | <Hixie> | and what about if the user draws a text box above another and says the first should flow to the second? should we have elements for positioned text flows? or columns? or any other presentational stuff? |
| 23:30 | <othermaciej> | exact positioning of images, generally not |
| 23:30 | <Hixie> | or what if the user says the underline should be dotted? |
| 23:30 | <AryehGregor> | Bold, italic, and underline *always* affect the meaning of the text in some way. Unless you're talking about some illiterate sign put up by someone who applies them at random. |
| 23:30 | <Hixie> | basically i'm saying i don't understand what is special about <u> |
| 23:30 | <AryehGregor> | Hixie, huh? What does "draws a text box above another" mean? |
| 23:30 | <Hixie> | AryehGregor: do you have Pages.app by any chance? |
| 23:30 | <TabAtkins> | AryehGregor: In a layout manager for a magazine, for example, or something similar. |
| 23:31 | <AryehGregor> | Hixie, virtually every WYSIWYG editor has a very prominent underline button. I don't even understand what these other things you're talking about are. |
| 23:31 | <AryehGregor> | Hixie, if that implies having Mac, then no. |
| 23:31 | <AryehGregor> | TabAtkins, that's a very atypical use-case compared to basic inline formatting. |
| 23:31 | <AryehGregor> | Zillions of blogs allow HTML-formatted comments, practically no one formats magazines using a web app. |
| 23:31 | <othermaciej> | if you think of producing a publication as a process where one person does the writing, and a different person does layout, bold/italic/underline are generally added by the writer, while many of the other things Hixie mentions would be done by the person in charge of layout |
| 23:31 | <Hixie> | in Pages, the ability to position text is more prominently displayed in the UI than the ability to underline text |
| 23:31 | <TabAtkins> | Huh? It's very typical in print publishing, which is getting closer and closer to being doable with high fidelity using web technologies. |
| 23:32 | <AryehGregor> | Print publishing is a very uncommon use-case, compared to marking up blog comments or forum posts. |
| 23:32 | <AryehGregor> | It's a specialty thing that almost no one will ever be involved in. |
| 23:32 | <Hixie> | we shouldn't be encouraging people to underline text on the web in those contexts anyway, since it's bad ui (clashes with links) |
| 23:32 | <TabAtkins> | Wait until Named Flows (a proposal from Adobe) get implemented. |
| 23:32 | <othermaciej> | most links on the web are not underlined by default these days |
| 23:33 | <othermaciej> | most that I see underline only on hover |
| 23:33 | <Hixie> | (pretty much everything i've described is either in css or has been proposed for css, fwiw) |
| 23:34 | <othermaciej> | but anyway, I don't want to debate |
| 23:34 | <AryehGregor> | It's still just not anywhere near as common as underlining. |
| 23:34 | <othermaciej> | was just trying to contribute ideas for a sensible definition |
| 23:34 | <othermaciej> | I must admit I do not fully grok the distinctions among the existing valid phrasing elements |
| 23:34 | <othermaciej> | so I am perhaps not the best person to make suggestions |
| 23:36 | <Hixie> | AryehGregor: i don't really see much underlining around the web, personally, except for links |
| 23:36 | <Hixie> | AryehGregor: and when i do see it it tends to be bad typography |
| 23:36 | <AryehGregor> | Hixie, didn't the CP say that <u> is the sixth most common phrasing element or something like that? |
| 23:36 | <AryehGregor> | I agree that it's bad typography, almost always. |
| 23:36 | <AryehGregor> | Underlines are only really appropriate for typewriters and handwriting. |
| 23:37 | <AryehGregor> | But users expect them, so authors will add the functionality one way or another. |
| 23:37 | <TabAtkins> | AryehGregor: We established a few days ago, I thought, that it's used on a fairly small percentage of sites. I guess it's just used a lot on those sites. |
| 23:37 | <AryehGregor> | No need to make their lives difficult. |
| 23:37 | <Hixie> | AryehGregor: <br> was the 8th-most used element of all in 2005, doesn't mean we should encourage its use |
| 23:37 | <AryehGregor> | I don't see any point in discouraging it. |
| 23:37 | <AryehGregor> | But then, I don't have a problem with presentational markup per se. |
| 23:38 | <AryehGregor> | So it's kind of hard to have any sort of discussion with you about this kind of thing. |
| 23:38 | <Hixie> | AryehGregor: and <table> was the 9th, well above <p> |
| 23:38 | <TabAtkins> | I see a lot of reason to discourage it, from seeing novices abuse it and create layouts that break in different resolutions. |
| 23:38 | <Hixie> | AryehGregor: you don't have a problem with media-specific presentation? |
| 23:38 | <TabAtkins> | Back when I was a webdev, the person from Marketing I worked with would occasionally write HTML, and pretty much every use of <br> was a misuse that I had to fix. |
| 23:39 | <Hixie> | pretty much every use of <br> in general is a misuse, indeed |
| 23:39 | <AryehGregor> | Hixie, in the real world, no. It's best if you can do things media-independent, and we should try to design the language to be easy to use in a media-independent fashion, but there are always limits. I don't have a problem with the fact that the overwhelming majority of authors test only in conventional browsers. |
| 23:39 | <nessy> | hehe - sometimes it's easier than div clear both ;-) but yeah... |
| 23:39 | <AryehGregor> | Nor with the fact that they only care about conventional browsers. |
| 23:40 | <Hixie> | they shouldn't have to test it at all |
| 23:40 | <TabAtkins> | nessy: That was, by far, the most common reason I had to correct it - it was being used as a poor-man's clear. |
| 23:40 | <TabAtkins> | nessy: Which usually broke in different screen widths. |
| 23:40 | <AryehGregor> | All software has to be tested if you want it to work well. |
| 23:40 | <AryehGregor> | I agree that we should be trying to design the language so that a page only tested in conventional browsers works okay in other UAs too. |
| 23:41 | <Hixie> | that goal is entirely incompatible with presentational markup. |
| 23:42 | <othermaciej> | what would unconventional UAs be able to do better if the [U] button in editor UI inserted something other than <u>? |
| 23:42 | <AryehGregor> | Not really. Other UAs can just skip the presentation, and the meaning will typically be preserved. Or they can adopt some convention to render it in their preferred medium, even if it's not normal for that medium. |
| 23:42 | <Hixie> | othermaciej: the state of the art is such that WYSIWYG editors can't create good media-independent pages. |
| 23:42 | <AryehGregor> | E.g., if users of screen readers wanted to know what text was italicized, the UA could read italic text in a different voice or something, or say "italics" before reading it, or such. |
| 23:42 | <Hixie> | othermaciej: hence why i originally had <font> as conforming, but just for wysiwyg editors |
| 23:43 | <AryehGregor> | Then they know the text was italicized, which is enough to grasp the meaning as well as someone actually viewing it. |
| 23:43 | <Hixie> | othermaciej: i'm fine with <u> being just for those editors |
| 23:43 | <nessy> | what problem exactly is introduced by allowing <u>? |
| 23:43 | <Hixie> | AryehGregor: that is treating those users as second-class citizens, which is imho quite immoral. |
| 23:44 | <nessy> | I also want it in WebVTT, btw, because captions have it and we don't have links there, so there is no confusion |
| 23:44 | <AryehGregor> | Hixie, do you think authors are morally obligated to spend a disproportionate amount of their time on a tiny minority of their users? |
| 23:44 | <TabAtkins> | Do you think that <u> saves a "disproportionate amount of [author] time"? |
| 23:44 | <othermaciej> | so there's a possible definition - "The u element represents a span of text that a user chose to underline without expressing a specific semantic." |
| 23:45 | <Hixie> | AryehGregor: there is no need to spend any time over any subset of one's users if one uses semantic markup |
| 23:45 | <TabAtkins> | othermaciej: That's just "this element is presentational". ^_^ |
| 23:45 | <Hixie> | othermaciej: yeah, that's what i suggested earlier |
| 23:45 | <AryehGregor> | Hixie, that's just not true in practice. |
| 23:45 | <AryehGregor> | TabAtkins, no, but once you're okay with presentational markup, there's no reason to disallow <u>. |
| 23:45 | <Hixie> | AryehGregor: it really is |
| 23:46 | <TabAtkins> | IIRC, the major motivation for <u> was to save bytes over <span style="text-decoration:underline;">. |
| 23:46 | <AryehGregor> | Hixie, if that were true, then you'd expect authors to widely use semantic markup. The fact that they aren't indicates that there's some cost to it. Maybe education, maybe the actual use -- but if the benefit significantly outweighed the cost, it would be popular. |
| 23:46 | <Hixie> | once you're ok with presentational markup, there's no reason to disallow <center>, <table border>, <font>, bgcolor="", etc, either |
| 23:46 | <AryehGregor> | Hixie, I've already addressed that point multiple times. |
| 23:46 | <AryehGregor> | I'm okay with allowing anything that would be widely used and is a simple shortcut for equivalent CSS markup. |
| 23:47 | <AryehGregor> | None of the items you mention qualify. |
| 23:47 | <AryehGregor> | (although I think <table border=1> should be valid for different reasons) |
| 23:47 | <Hixie> | AryehGregor: there are two reasons people don't use semantic markup; the cognitive (people don't think semantically), and wysiwyg editors. |
| 23:47 | <AryehGregor> | Hixie, sure. Both of those are legitimate disadvantages, and they normally outweigh the advantages by a large margin. |
| 23:48 | <kennyluck> | Before I see more examples how <b> and <i> are styled, I don't think the cognitive part can make any improvement. |
| 23:48 | <Hixie> | AryehGregor: but in both cases it is _using presentational markup_ that leads to spending "a disproportionate amount of their time on a tiny minority of their users" |
| 23:49 | <Hixie> | AryehGregor: if you just used semantic markup, you'd spend all your markup time on all your users, and some additional time on just visual users (writing the css) |
| 23:49 | <Hixie> | AryehGregor: we're not going to solve either of those problems by adding <u> |
| 23:49 | <AryehGregor> | Hixie, assuming you understand semantic markup to begin with, and that it's not more efficient for you to use a WYSIWYG editor. |
| 23:49 | <Hixie> | AryehGregor: we might help the first a little by not having <u> |
| 23:49 | <AryehGregor> | Both of those are illegitimate assumptions. |
| 23:49 | <Hixie> | if you use a wysiwyg editor, non-visual users are a lost cause |
| 23:49 | TabAtkins | suggests that AryehGregor spend some time maintaining a large site that was written by a dev who used layout tables and presentational markup heavily. |
| 23:50 | <Hixie> | so that case isn't really interesting to this discussion |
| 23:50 | <AryehGregor> | TabAtkins, separate issue. You can write easy-to-maintain code that uses only appropriately-classed spans and divs, with no semantic markup at all. |
| 23:50 | <TabAtkins> | I have never seen such a thing. |
| 23:50 | <AryehGregor> | You can write bad code in any language. |
| 23:50 | <Hixie> | i don't have a problem making a second set of conformance criteria for wysiwyg editors while the state of the art there is where it is |
| 23:50 | <TabAtkins> | I consider it a theoretical case that doesn't exist in practice. |
| 23:50 | <AryehGregor> | Well, for one thing, you could be using Dreamweaver or something. |
| 23:51 | <AryehGregor> | But we're talking about <u>, not table-based layout. |
| 23:51 | <TabAtkins> | Use of <u> was also rampant in the last large site I maintained. |
| 23:51 | <AryehGregor> | Hixie, WYSIWYG editors are probably the most important issue at stake for <u>. |
| 23:52 | <Hixie> | AryehGregor: the CP asks for <u> to be always conforming, not just for editors |
| 23:52 | <AryehGregor> | Hixie, because there's no way to tell if something was written by an editor. |
| 23:52 | <Hixie> | AryehGregor: i'd be fine with making <u> just valid for editors, just like omitting alt="" is valid just for editors. |
| 23:52 | <Hixie> | AryehGregor: there's no way to tell if the contents of an <h1> are a heading either, but we still require that |
| 23:53 | <Hixie> | AryehGregor: we can have different conformance criteria for hand authors than for editors |
| 23:53 | <Hixie> | AryehGregor: that's not a problem |
| 23:53 | <Hixie> | AryehGregor: indeed we did, at some point in the past |
| 23:53 | <AryehGregor> | Hixie, I don't care as long as the validator doesn't complain. As far as I'm concerned, authoring conformance requirements that aren't machine-checkable are your personal opinion and they don't affect me. |
| 23:53 | <AryehGregor> | (unless I happen to agree with them) |
| 23:53 | <AryehGregor> | However, the CP might be construed not to allow this. |
| 23:53 | <Hixie> | so you'd be ok with <u> being only valid if the document has a <meta name=generator> element? |
| 23:54 | <AryehGregor> | No. |
| 23:54 | <Hixie> | i rest my case |
| 23:54 | <AryehGregor> | Who says WYSIWYG-edited pages always actually produce that? |
| 23:54 | <Hixie> | we can say that |
| 23:54 | <AryehGregor> | In particular, part of the page might be WYSIWYG-edited. |
| 23:54 | <Hixie> | "editors must include..." |
| 23:55 | <AryehGregor> | That will lead to people including <meta name=generator> to shut up the validator. |
| 23:55 | <AryehGregor> | Even on hand-edited pages. |
| 23:55 | <Hixie> | well people can always shut up the validator |
| 23:55 | <Hixie> | validators are tools |
| 23:55 | <Hixie> | you can always take the battery out of the smoke detector |
| 23:56 | <AryehGregor> | Allowing people to shut up the validator by including useless cruft is an antipattern. |
| 23:56 | <Hixie> | no, it's adding the useless cruft that's the antipattern |
| 23:56 | <AryehGregor> | We had too much of that in the old days, things like type="text/javascript" and so on. |
| 23:56 | <AryehGregor> | Well, as I said, I don't think we're ever going to agree on this, so go ahead and make any change you like that's compatible with the CP. |
| 23:56 | <othermaciej> | I'll just note that, while almost any prose expressing non-machine-checkable requirements on <u> contents is likely consistent with the decision, limiting it to documents with <meta name=generator> likely is not |
| 23:56 | <Hixie> | the difference there is that type="" was useless, whereas the generator mark serves a useful purpose: distinguishing editor-autogenerated pages from hand-authored pages |
| 23:57 | <Hixie> | my real concern is what to do in the whatwg copy |
| 23:57 | <Hixie> | not the w3c copy |
| 23:57 | <AryehGregor> | Ah. |
| 23:57 | <AryehGregor> | I wonder which one the validator will follow. |
| 23:57 | <Hixie> | if i don't include <u>, then henri will probably follow a hybrid |
| 23:58 | <Hixie> | so i plan to include <u> |
| 23:58 | <Hixie> | just not sure how to include it |