| 03:50 | <boblet> | Hixie: a little OT, but I noticed you’re the CSS3 generated content editor. How should generated content-inserted images be positioned? position:absolute seems overkil but margin/padding/vertical-align don’t seem to work… |
| 06:27 | <eighty4> | gsnedders|work: you like sushi? |
| 07:19 | <eighty4> | gsnedders|work: got by "do you like sushi?" question? |
| 08:55 | <gsnedders|work> | eighty4: yes, I got the question. No, I do not. |
| 08:56 | <eighty4> | gsnedders|work: :) |
| 08:56 | <eighty4> | gsnedders|work: any preferenses? |
| 08:56 | <jgraham> | silly gsnedders |
| 08:57 | <gsnedders|work> | eighty4: Something I like. |
| 08:57 | <gsnedders|work> | (Which is most non-spicy stuff, which at lunch time means almost anywhere is fine.) |
| 08:57 | <gsnedders|work> | (Just not sushi.) |
| 09:02 | <eighty4> | gsnedders|work: I'm not really eating lunch down down that much. Any suggestions? |
| 09:03 | <gsnedders|work> | eighty4: We normally go to either Kikkobar or Yogi, occasionally further afield |
| 09:07 | <eighty4> | gsnedders|work: want to try something new or just go to Yogi? |
| 09:08 | <annevk2> | you don't like sushi? dude |
| 09:09 | <gsnedders|work> | That's it, I'm going to Mini to get away from you and jgraham! |
| 09:09 | <annevk2> | so far I'm just stalking you on IRC |
| 09:09 | <gsnedders|work> | eighty4: Well, there's likely going to be a large number of p[eople from Opera there today as one of the things they have is raggmonk, though that said I'm perfectly happy to go there |
| 09:10 | <gsnedders|work> | I… I… I… saw you when I got to work today! |
| 09:10 | <eighty4> | :| |
| 09:11 | <eighty4> | don't like raggmunk |
| 09:11 | <gsnedders|work> | They have other things too |
| 09:11 | <eighty4> | gsnedders|work: oho? on the bus? |
| 09:11 | <eighty4> | :) |
| 09:11 | <eighty4> | then lets go there |
| 09:11 | <gsnedders|work> | They had a really spicy curry… |
| 09:11 | <gsnedders|work> | And something else |
| 09:11 | <gsnedders|work> | eighty4: oho? |
| 09:13 | <gsnedders|work> | I'd rather go somewhere in the centre myself, though |
| 09:13 | <gsnedders|work> | But maybe I'm bias |
| 09:20 | <annevk2> | so zcorpan_ I can just use "xml-stylesheet processing instruction" as term I suppose? |
| 09:23 | <eighty4> | gsnedders|work: sure, its up to you. I just don't know what's good and whats not |
| 09:23 | <Dashiva> | Why not McDonalds? |
| 09:26 | <eighty4> | Dashiva: that's no fun |
| 09:26 | <gsnedders|work> | Dashiva: We have this thing called "sanity". |
| 09:43 | <gsnedders|work> | eighty4: Do you want to meet outside Kikkobar? We can then look there and elsewhere… |
| 09:43 | <gsnedders|work> | eighty4: Any idea of time? |
| 09:44 | <eighty4> | gsnedders|work: could meat outside opera, it's on the way for me. Around 12 ? |
| 09:44 | <eighty4> | we usally eat 12 here |
| 09:45 | <gsnedders|work> | eighty4: That means going out of the front entrance :P |
| 09:45 | <gsnedders|work> | eighty4: Sure, though |
| 09:46 | <eighty4> | gsnedders|work: you don't happen to know how I can get the year form a /blog/2009 wordpress link? |
| 09:46 | <gsnedders|work> | eighty4: See: #wordpress |
| 09:46 | <gsnedders|work> | eighty4: I haven't touched most of WP in years |
| 09:46 | <eighty4> | gsnedders|work: just asked in there, but it's usally so quite :/ |
| 09:47 | <gsnedders|work> | #wordpress-dev is more active, but you'll be screamed at if you ask any support questions there |
| 09:53 | annevk2 | now has enough memory to actually run the VirtualBox |
| 09:54 | <annevk2> | my machine became somewhat noisy though |
| 09:55 | <Philip`> | Adding memory made it noisy? |
| 09:55 | <annevk2> | running more software did I think |
| 10:01 | <annevk2> | hmm, the Link header supports multiple title parameters right? |
| 10:01 | <annevk2> | guess I'll just pick whatever is the first |
| 10:01 | <Hixie> | i think mark changed it so it can only have one title and maybe multiple title* |
| 10:02 | <Hixie> | though i'm not sure what software he expects to implement title* |
| 10:02 | <Hixie> | (and he wouldn't, or didn't, tell me, iirc) |
| 10:06 | <annevk2> | so either title or the first title* whichever is first? |
| 10:06 | <annevk2> | grmbl |
| 10:06 | <Hixie> | title* is some complex thing with languages |
| 10:06 | <annevk2> | CSSOM just has a single concept of title |
| 10:06 | <Hixie> | oh this is for CSSOM, not an implementation? |
| 10:06 | <annevk2> | yeah, there's the "style sheet title" |
| 10:07 | <Hixie> | i would recommend having the alternative style sheet stuff just say to use title and ignore title*, but I guess that screws over non-english locales, since the HTTP guys refuse to use UTF-8 still (!) |
| 10:07 | <Hixie> | so yeah, you'll have to require the crazy title* processing |
| 10:07 | <annevk2> | the claim is that UTF-8 is not backwards compatible enough with iso-8859-1 what HTTP supposedly is in |
| 10:07 | <gsnedders|work> | There are plenty of cases where that claim is true |
| 10:08 | <annevk2> | I think that may be true for some set of the headers, but definitely not all |
| 10:08 | <Hixie> | i thought HTTP was ASCII |
| 10:08 | <Hixie> | it's 8859-1? |
| 10:08 | <annevk2> | yeah |
| 10:08 | <annevk2> | that's the main issue |
| 10:09 | <annevk2> | e.g. with HTTP auth you definitely have non-ASCII characters in passwords and such |
| 10:09 | <hsivonen> | but it's possible to distinguish UTF-8 from ISO-8859-1 with good enough confidence |
| 10:10 | <hsivonen> | does the IETF not do "good enough confidence"? |
| 10:10 | <Hixie> | you could just have a header that triggers UTF-8 processing, too |
| 10:10 | <Hixie> | like Content-Type but for headers |
| 10:10 | <Hixie> | anyway |
| 10:10 | <Hixie> | not my problem |
| 10:13 | <zcorpan_> | it's possible to use utf-8 in headers with base64 escaping, no? |
| 10:13 | <gsnedders|work> | Hixie: For streaming processing that'd mean having it before other headers, and that means making the order of headers important |
| 10:13 | <zcorpan_> | Foo-Header: =UTF-8=...base64...= |
| 10:13 | <gsnedders|work> | zcorpan_: For BASIC auth, yeah. Nothing else uses base64 AFAIK |
| 10:13 | <Hixie> | gsnedders|work: and the problem with that would be...? |
| 10:14 | <Hixie> | (it could also be on the first line) |
| 10:14 | <gsnedders|work> | Hixie: Changing something from having order with no meaning to having order with meaning is a fairly major change |
| 10:14 | <zcorpan_> | at least i've used that for sending emails for the From header etc |
| 10:14 | <gsnedders|work> | Hixie: Changing the first line breaks strict implementations, and would rely upon unspecified headers |
| 10:15 | <gsnedders|work> | zcorpan_: Ah, you can in MIME, sure. Not in HTTP. |
| 10:15 | <zcorpan_> | ok |
| 10:15 | <Hixie> | gsnedders|work: sounds like excuses to me |
| 10:15 | <gsnedders|work> | s/headers/behaviour in other implementations/ |
| 10:17 | <gsnedders|work> | Hixie: Given a streaming processor and one that does all the processing at once, if the header is not the first header, it can easily effect all headers after it still in the streaming impl, but can only effect either all headers or no headers in the non-streaming one. There are major issues with adding a header for it too., |
| 10:17 | <gsnedders|work> | Hixie: It's technically a horrible thing to change without requiring quite a lot of implementations to be rewritten in a large way |
| 10:18 | <Hixie> | gsnedders|work: adding Unicode support requires implementation changes regardless of what the solution is |
| 10:18 | <Hixie> | gsnedders|work: i'd rather have a change that, e.g., made it so the second line was some magic features-enabling line, than having to use the asinine =?= nonsense |
| 10:19 | <hsivonen> | Base64 in HTTP would be terrible |
| 10:19 | <gsnedders|work> | Hixie: I guess you could get away with making the second line magic if you could live without defined error handling if it wasn't the first |
| 10:19 | <gsnedders|work> | s/first/second/ |
| 10:19 | <annevk2> | the problem is that both servers and clients have to change |
| 10:19 | <gsnedders|work> | It also wouldn't degrade nicely |
| 10:19 | <Hixie> | why couldn't you define error handling? |
| 10:19 | <annevk2> | i.e. clients cannot suddenly start sending out UTF-8 for all HTTP requests |
| 10:19 | <gsnedders|work> | Hixie: See what I said above. At a protocol level, you can't break 50% of clients/servers. |
| 10:20 | <gsnedders|work> | It's a backwards incompatible protocol change. |
| 10:20 | <Hixie> | what i'm proposing wouldn't break anything. old uas would just ignore the unknown header. |
| 10:20 | <gsnedders|work> | It can't really be done until HTTP/2.0 |
| 10:20 | <gsnedders|work> | Hixie: And then wouldn't work with the data passed. Couldn't ever log-in, for example. |
| 10:20 | <hsivonen> | gsnedders|work: can't or the WG won't? |
| 10:20 | <Hixie> | that's the case with the current solution too! |
| 10:21 | <gsnedders|work> | hsivonen: I'd say there are good technical reasons it couldn't be done until 2.0 |
| 10:22 | <annevk2> | how does a version number help matters? |
| 10:22 | <Hixie> | i am not even remotely convinced of that, but even if we grant that, wtf are we waiting for then? |
| 10:22 | <annevk2> | you still have the same client/server issue |
| 10:22 | <hsivonen> | what are the practical problems of saying that HTTP headers are UTF-8 if they decode as UTF-8 without error and Windows-1252 otherwise? |
| 10:22 | <Hixie> | let's do HTTP 2.0 already |
| 10:22 | <gsnedders|work> | Hixie: Indeed. We should've done 2.0 years ago. |
| 10:22 | <hsivonen> | I predict there will never be 2.0 |
| 10:23 | <gsnedders|work> | hsivonen: Likewise. |
| 10:23 | <hsivonen> | for the same reason XML 1.1 flopped |
| 10:23 | <Hixie> | but i don't buy your argument. either hsivonen's idea or my own can work fine in a 1.2 (or 1.1bis). |
| 10:23 | <Hixie> | without breaking things |
| 10:23 | <eighty4> | gsnedders|work: I'll ping you here before I go. Should take me a couple of minutes to get outside Opera |
| 10:23 | <gsnedders|work> | eighty4: No need to ping me |
| 10:23 | <gsnedders|work> | It doesn't take me long to get downstairs :) |
| 10:24 | <eighty4> | gsnedders|work: just so that you don't need wait for me |
| 10:24 | <hsivonen> | we are lucky we aren't trying to develop interoperable DRM systems |
| 10:24 | <hsivonen> | Web interop is easier :-) |
| 10:25 | <Hixie> | DRM systems are impossible |
| 10:25 | <Hixie> | speaking of which... Lachy, yt? |
| 10:27 | Philip` | saw the marketing material for his new monitor said "HDCP is not designed to prevent copying or recording of digital content but to protect the integrity of content as it is being transmitted" |
| 10:27 | <Philip`> | I can't work out who they're trying to protect the integrity against, other than me |
| 10:27 | <zcorpan_> | Philip`: could you merge video.html and media.html in the multipage version? |
| 10:27 | <Hixie> | Philip`: wow, what a crock |
| 10:28 | <gsnedders|work> | Hixie: Also, there's the political reasons of 1.1bis not being chartered to extend HTTP |
| 10:28 | <Hixie> | more excuses |
| 10:29 | <Philip`> | zcorpan_: Hmm, I thought I'd already done that, but maybe I'd just said "I'll do that some time soon" when you first asked ages ago :-/ |
| 10:29 | <hsivonen> | Philip`: if you want to protect the integrity of the signal, you should get an HDMI cable with gilded connectors :-) |
| 10:30 | <gsnedders|work> | Hixie: For better or for worse, WGs normally operate under specific charters, and will get in trouble if they don't stick to them. At least in the IETF other people can as individuals write specs |
| 10:31 | <Philip`> | zcorpan_: Done |
| 10:31 | <Hixie> | gsnedders|work: that's BS. The charters don't just come out of thin air. If the group really wanted to solve problems instead of just gilding the current ones, they'd write a charter that gave them the authority to do so. |
| 10:32 | <gsnedders|work> | Hixie: Most WGs don't have the authority to write charters to give themselves authority |
| 10:32 | <Hixie> | nonsense |
| 10:32 | <Hixie> | all WGs write their own charter |
| 10:33 | <Hixie> | it's not like other people say "oh hey, people over there, here's a job for you to do" |
| 10:33 | <gsnedders|work> | They still need to be approved, and there are times when pushing endlessly won't help |
| 10:33 | <Hixie> | they don't need to be approved |
| 10:33 | <Hixie> | as exhibit A i present the whatwg. |
| 10:35 | <gsnedders|work> | Hixie: If you want to get your spec published by any normal organization which you need for anyone to pay attention to it. |
| 10:35 | <Hixie> | again, nonsense. HTML5 had attention paid to it without a "normal organisation" publishing it. |
| 10:35 | <Hixie> | you get attention by addressing the needs of the implementors and authors. |
| 10:36 | <gsnedders|work> | Hixie: Yes, but it also had one browser vendor writing it and others participating |
| 10:36 | <Hixie> | right, _that_'s what you need |
| 10:36 | <Hixie> | the w3c and ietf publish plenty of drafts that nobody pays attention to |
| 10:36 | <Hixie> | and they are not required (and indeed are of little help, imho) for people to pay attention to you |
| 10:36 | <gsnedders|work> | Hixie: Writing a spec from scratch without a browser vendor being involved in writing it is very hard to get any browser vendor to care about, as far as I can tell |
| 10:37 | <gsnedders|work> | (as in, an employee of the vendor writing it) |
| 10:37 | <gsnedders|work> | Or at least that was my experience with HTTP parsing |
| 10:37 | <Hixie> | pingback got the attention of the blog software writers without the writer working for a blog software company |
| 10:37 | <gsnedders|work> | That assumes blog software is like browsers |
| 10:37 | <gsnedders|work> | That doesn't follow. |
| 10:37 | <Hixie> | fair enough, but in that case, just get the browser vendors on board |
| 10:38 | <Hixie> | who from the browser vendors is on board with http? |
| 10:38 | <gsnedders|work> | I _tried_. |
| 10:38 | <gsnedders|work> | Out of all the major implementers, the only one I got much out of was IIS! |
| 10:39 | <gsnedders|work> | There are a few people from each browser vendor on the httpbis list |
| 10:39 | <Hixie> | i'm not really sure what point your trying to make here. The point I'm trying to make is that the red tape and bureaucracy arguments are a smoke screen and that if a WG actually wants to make significant progress, they can do so regardless of the process rules. |
| 10:39 | <Hixie> | (and that the httpwg isn't an example of this.) |
| 10:40 | <gsnedders|work> | My point is making significant progress within browsers is hard to do without a browser vendor writing the spec, as far as I can tell. |
| 10:40 | <Hixie> | (it looks like the URI/IRI world might become an example of this, though; larry, amongst others, really does seem to want to tackle the hard problems. we'll see how well that goes. I have good hopes.) |
| 10:40 | <Hixie> | i don't think that's true, but I do agree that if you want browsers to implement your feature, you have to have their buy-in. |
| 10:40 | <Hixie> | but then you want that anyway |
| 10:41 | <Hixie> | so i don't see why that's a problem |
| 10:41 | <gsnedders|work> | That was very much my experience with HTTP parsing, when I was working on it. |
| 10:41 | <Hixie> | if you didn't get a browser vendor writing the spec, how do you know that's what would have been necessary? |
| 10:42 | <Hixie> | it could just be that you weren't addressing the problems they wanted addressing |
| 10:42 | <Hixie> | (not saying it was, i'm just saying that it seems to me that there are many possible explanations that match what you've described other than the one you've given) |
| 10:42 | <gsnedders|work> | Hixie: The couple of occasions I did anything over the summer I got more information out of people than I did before. |
| 10:43 | <gsnedders|work> | Hixie: As far as I can tell, nothing changed in the month (or two?) between me working on it apart from me then having an opera.com email address. |
| 10:43 | <Hixie> | over time and as you form more relationships with people in the community and gain more respect and trust from people in the community, people will respond more |
| 10:44 | <Hixie> | having an opera.com address means you passed the "not a moron" filter that opera applies to hires |
| 10:44 | <Hixie> | other people use that as a (probably subconscious) guide to how much they should respect/trust you |
| 10:44 | <gsnedders|work> | I still think it is very true that who you work for does play a significant role in getting people working on stuff |
| 10:44 | <Hixie> | i think it's certainly a big influence, yes |
| 10:44 | <Hixie> | but i don't think it's a requirement |
| 10:45 | <gsnedders|work> | Right, I think if you already have the influence, you can get away without |
| 10:45 | <Hixie> | that's how life works in general |
| 10:45 | <jgraham> | I swear gsnedders|work types more loudly when he is disagreeing |
| 10:45 | <Hixie> | hah |
| 10:45 | <eighty4> | gsnedders|work: I'm on my way now. Outside Opera in 4? |
| 10:46 | <gsnedders|work> | The problem is getting any influence whatsoever in the spec world is fairly difficult, as far as I can tell |
| 10:46 | gsnedders|work | makes an effort to type more quietly |
| 10:46 | <Hixie> | getting influence anywhere is hard |
| 10:46 | <Hixie> | you basically have to earn it by proving ability over many years |
| 10:46 | <Hixie> | and it's trivial to lose it |
| 10:46 | <gsnedders|work> | (But yes, it is true that I do in general type fairly loudly) |
| 10:47 | <Hixie> | in my experience the easiest way to gain it is just do Do Stuff |
| 10:47 | <Hixie> | e.g. i got of lot of mileage out of writing a bazillion test cases and filing bugs while i was at university |
| 10:47 | <gsnedders|work> | Hixie: My experience with HTTP parsing is there is little point in trying to edit any spec until you have a certain amount of influence |
| 10:48 | eighty4 | pokes gsnedders|work |
| 10:48 | <gsnedders|work> | eighty4: Yes, I saw |
| 10:48 | <Hixie> | there's probably little point trying to get people to do something (anything) until you have influence, yes |
| 10:48 | <eighty4> | :) |
| 10:48 | <gsnedders|work> | eighty4: I have another two minutes :) |
| 10:48 | eighty4 | disapears |
| 10:48 | <Hixie> | whether that's by editing the spec or something else |
| 10:48 | <gsnedders|work> | Hixie: The few things I've started in Atom land got further, but equally I have more experience with shipping stuff there |
| 10:49 | <gsnedders|work> | Anyhow, I better head downstairs now and head out to lunch |
| 10:49 | <Hixie> | later |
| 10:55 | Hixie | opens a bazillion intl.properties files |
| 11:13 | annevk2 | wonders how Opera hides document.all |
| 11:14 | <annevk2> | jgraham? |
| 11:14 | <jgraham> | annevk2: Not sure. I was wondering the same thing |
| 11:23 | <othermaciej> | my mega-thread with Brendan is a little out of control |
| 11:23 | <hsivonen> | Hixie: I suggest making it clear that the motivation of the charset table is compat with existing content and that i18n enthusiasts shouldn't bikeshed it using forward-looking rationales |
| 11:24 | <Hixie> | done |
| 11:24 | <hsivonen> | othermaciej: does the public-html thread count as mega-thread or is there more to see elsewhere? |
| 11:25 | <Hixie> | i think he means on public-script-coord |
| 11:25 | <hsivonen> | oh |
| 11:27 | <othermaciej> | the combination of the two |
| 11:28 | <jgraham> | annevk2: It _seems_ to be an ordinary object that happens to ToBoolean to false |
| 11:29 | hsivonen | wonders if the UTF-8 locales are really maximally successful defaulting to UTF-8 or if it is more about politics |
| 11:29 | <annevk2> | so yeah, we override ToBoolean and typeof |
| 11:29 | <othermaciej> | annevk2: I guess that's basically the same as what WebKit does |
| 11:29 | <annevk2> | Gecko "fails" in many ways according to at least one Opera dev |
| 11:29 | <hsivonen> | I'm pretty surprised that Arabic and Vietnamese don't default to the Windows-* encodings |
| 11:30 | <othermaciej> | annevk2: that would be useful info |
| 11:30 | <jgraham> | annevk2: And [[HasProperty]] or whatever it is called |
| 11:31 | <othermaciej> | oddly in WebKit we don't override HasProperty, so ("all" in document) is true |
| 11:31 | <othermaciej> | not a lot of people test that way, although I think the in operator is arguably the best way to do feature testing |
| 11:32 | <jgraham> | The Opera behaviour seems pretty simple. We sould standardise it ;) |
| 11:32 | <jgraham> | *should |
| 11:32 | <othermaciej> | actually, ("all" in document) is true in the Opera I'm testing |
| 11:33 | <jgraham> | oops I was loooking at the wrong browser |
| 11:33 | <Philip`> | http://google.com/codesearch?q=%5C%22all%5C%22%5C+in%5C+document |
| 11:33 | <othermaciej> | it sounds like Opera's behavior is likely to be more or less the same as WebKit |
| 11:33 | <jgraham> | We indeed don't override [[HasProperty]] although I think we should |
| 11:34 | <othermaciej> | I think that would be easier to do than all the other all-related hackery |
| 11:34 | Philip` | wonders what uuppa-js is, but all the documentation seems to be Japanese |
| 11:34 | <othermaciej> | Philip`: I'm curious about the result that's not in the Gecko regression tests |
| 11:35 | <annevk2> | aah, I forgot how Hixie made everything influence the style sheet disabled flag |
| 11:36 | <othermaciej> | Hixie, hsivonen: some of my colleagues were doubting the wisdom of rejecting EBCDIC-based encodings and UTF-32 |
| 11:36 | <annevk2> | othermaciej, we haven't had a single report |
| 11:36 | <othermaciej> | (we just blacklisted UTF-7 and will likely add the other mandatory banned encodings) |
| 11:36 | <annevk2> | othermaciej, Opera 10 doesn't support either |
| 11:36 | <othermaciej> | annevk2: interesting |
| 11:36 | <othermaciej> | thanks for that data |
| 11:37 | <annevk2> | Opera overall hasn't supported EBCDIC since like ever |
| 11:37 | <Hixie> | othermaciej: let me know when you find a UTF-32 page |
| 11:37 | <annevk2> | and we haven't had a request for it |
| 11:37 | <Hixie> | othermaciej: or, for that matter, an EBCDIC page |
| 11:37 | <annevk2> | UTF-32 was removed for Opera 10 and the only page we knew about was a test |
| 11:37 | <othermaciej> | we just accidentally support everything that ICU does |
| 11:37 | <annevk2> | othermaciej, I'd still appreciate a table of some kind btw for what ICU does |
| 11:37 | <othermaciej> | Hixie: I don't believe either exist, but there was some concern about intranet pages and whether those might outweigh the security benefit of banning oddball encodings |
| 11:37 | <annevk2> | othermaciej, for the Web Encodings page |
| 11:38 | <Hixie> | othermaciej: my priorities are different. :-) |
| 11:38 | <othermaciej> | annevk2: I don't think I can accurately describe what ICU does without reading the ICU source code |
| 11:38 | <othermaciej> | Hixie: in any case it sounds like the worry may be misplaced, based on what annevk2 says |
| 11:38 | <Philip`> | http://search.ultraseek.com/query.html?charset=cp037&qt=%3Cscript%3Ealert('oh%20%5Cx6eo')%3C/script%3E&oldqt=%3Cscript%3Ealert('oh%20%5Cx6eo')%3C/script%3E |
| 11:39 | <Philip`> | There's an EBCDIC page! |
| 11:40 | <othermaciej> | jgraham, annevk2: it might be useful to at least describe Opera's implementation of document.all, if there are flaws in the Gecko behavior those would be good to know too |
| 11:40 | <Philip`> | (Only does XSS in browsers that don't support EBCDIC, though) |
| 11:41 | <Dashiva> | How does that even work |
| 11:41 | <hsivonen> | the main use case for EBCDIC |
| 11:43 | <annevk2> | Hixie, this "style sheet set" stuff is a bit weird |
| 11:43 | <Lachy> | Hixie, I'm here now |
| 11:43 | <Hixie> | yes |
| 11:43 | <annevk2> | Hixie, it seems like it tries to be both a string and a collection of style sheets |
| 11:43 | <Dashiva> | .style ? |
| 11:44 | <annevk2> | Dashiva, no, think of alternative style sheets and all |
| 11:44 | <Hixie> | annevk2: i'm not at all familiar with what i wrote, though iirc it was pretty solid when you took it over |
| 11:44 | <annevk2> | well, it didn't really define any kind of model |
| 11:44 | <annevk2> | or when style sheets would actually apply etc. |
| 11:45 | <othermaciej> | being both a string and something else is awkard |
| 11:45 | <annevk2> | hmm |
| 11:46 | <Dashiva> | Isn't that how .style works, though? It's a collection of properties, but can also be read and assigned directly. |
| 11:46 | <annevk2> | Hixie, like HTML5 says to set the preferred style sheet to a string value and the text you wrote both talks about preferred style sheet set and the name of the preferred style sheet set somewhat interchangeably |
| 11:47 | <annevk2> | Dashiva, we're not discussing .style |
| 11:47 | <Dashiva> | I know |
| 11:47 | <Hixie> | annevk2: ah, that might need tightening up, yeah |
| 11:47 | <annevk2> | Hixie, I guess I'll go with style sheet set and style sheet set name then |
| 11:48 | <annevk2> | and something like "setting the preferred style sheet name" |
| 11:48 | <hsivonen> | Hixie: if a document has a script-created parser, should the synchronous SVG load event be able to do document.write()? |
| 11:48 | <hsivonen> | seems like badness if yes |
| 11:49 | <Hixie> | there's only one place that sets the magic for document.write() correctly enough for document.write() to "work" (as opposed to blowing away the document) |
| 11:49 | <Hixie> | and that's <script> in HTML |
| 11:49 | <gsnedders|work> | uk locale defaults to windows-1251? odd. |
| 11:50 | <hsivonen> | Hixie: insertion point is set all the time when the entire document is document.written, right? |
| 11:50 | <Hixie> | yeah, it would work in that case |
| 11:50 | <Hixie> | gsnedders|work: "uk" isn't "en-gb" |
| 11:50 | <hsivonen> | Hixie: I tentatively want to prohibit document.write() from SVG load event even when the insertion point is defined all the time |
| 11:50 | <Hixie> | hsivonen: how? |
| 11:50 | <gsnedders|work> | Hixie: What's uk then? |
| 11:51 | <eighty4> | United Kingdom :P |
| 11:51 | <Hixie> | gsnedders|work: i forget, but i remember doing a double take when looking at that |
| 11:51 | <gsnedders|work> | Hixie: Where is it defined what locale is what? Is it just ISO country codes? |
| 11:52 | <hsivonen> | Hixie: not sure yet. I will have to think this through some more |
| 11:52 | <Hixie> | gsnedders|work: i just copied what mozilla does. |
| 11:52 | <gsnedders|work> | Hixie: That's undefined! |
| 11:52 | <Hixie> | hsivonen: i'm happy to put an explicit "if SVG 'load' event, bail" into the d.w algorithm |
| 11:53 | <gsnedders|work> | Hixie: I'd make the assumption if I didn't know better it was ISO-3166-1 alpha-2 codes, and UK is reserved by request of the UK to stop it being used for other countries, and would assume it was used for GB! |
| 11:54 | <Hixie> | gsnedders|work: you're gonna make me look it up again aren't you |
| 11:54 | <gsnedders|work> | Hixie: I'm gonna make you spec it :) |
| 11:54 | <Hixie> | gsnedders|work: http://mxr.mozilla.org/l10n-mozilla1.9.1/source/uk/toolkit/chrome/global/intl.properties |
| 11:55 | <Hixie> | http://mozilla-europe.org/uk/ |
| 11:55 | <Hixie> | ukrain? |
| 11:55 | <Hixie> | ukraine, even |
| 11:55 | <Hixie> | http://mxr.mozilla.org/l10n-mozilla1.9.1/source/uk/browser/README.txt?raw=1&ctype=text/plain suggests so |
| 11:55 | <Hixie> | looks like it should be ua |
| 11:55 | <Hixie> | i'll fix the spec |
| 11:56 | <Hixie> | fixed |
| 11:56 | <gsnedders|work> | Hixie: By changing to ua? |
| 11:57 | <Hixie> | yes |
| 12:00 | <hsivonen> | I'm trying to figure out what other situations could cause scripts to run syncronously with the parser except </script> and the SVG load event |
| 12:01 | <hsivonen> | Hixie: does XBL2 run scripts synchronously with the parse when it binds to parser-inserted nodes or does it defer to the task queue like XBL1? |
| 12:01 | <Hixie> | off-hand I've no idea |
| 12:01 | <Hixie> | but i would want it to be async |
| 12:01 | <Hixie> | xbl2 was written before i had a firm handle on sync vs async events |
| 12:01 | hsivonen | wonders how XBL2 was defined before the task queue concept was specced |
| 12:03 | <hsivonen> | I think I'm going to prohibit document.write() if the parser is flushing tree ops and it's not specifically dealing with </script> |
| 12:03 | <hsivonen> | that should catch the SVG load event |
| 12:03 | <hsivonen> | and also avoid crashing if there are cases I am unaware of |
| 12:04 | <hsivonen> | even if in those cases prohibiting document.write() would currently be non-conforming per spec if the parser is script-created |
| 12:04 | <Hixie> | you can document.write() on a timeout, if you have document.open()ed first |
| 12:04 | <Hixie> | (or anywhere else) |
| 12:05 | <hsivonen> | timeouts can only run when the event loops spins |
| 12:05 | <gsnedders|work> | Hixie: Can you search the whatwg subscriber list for gsneddon@opera to check whether I'm still subscribed, seeming I get nothing? |
| 12:05 | <hsivonen> | and you can only get a nested event loop when the parser deals with </script>, right? |
| 12:05 | <Hixie> | hsivonen: oh, i see |
| 12:05 | <hsivonen> | ooooops. |
| 12:05 | <hsivonen> | if the SVG load event does sync XHR!!! |
| 12:05 | <hsivonen> | that would create a nested event loop |
| 12:05 | <hsivonen> | evil |
| 12:06 | <Hixie> | gsnedders|work: tis not |
| 12:06 | <Hixie> | gsnedders|work: want me to add it manually while i'm here? |
| 12:06 | <gsnedders|work> | Hixie: Can you try adding it? |
| 12:07 | <remysharp> | gsnedders|work Is the outliner up to date, as in the parsing rules from the spec? |
| 12:07 | <Hixie> | done |
| 12:07 | <Hixie> | you are member 1203. |
| 12:07 | <gsnedders|work> | remysharp: The actual html5 parsing or the outlining algorithm? |
| 12:07 | <hsivonen> | nested event loops are unhappiness |
| 12:07 | <remysharp> | gsnedders|work: I think I mean the outlining algorithm |
| 12:08 | <Hixie> | hsivonen: technically, html5 never spins nested event loops |
| 12:08 | <gsnedders|work> | remysharp: Unless Hixie changed it in September, which AFAIK he did not, yes. |
| 12:08 | <hsivonen> | Hixie: how does HTML5 do alert() or sync XHR? |
| 12:09 | <Hixie> | hsivonen: alert() just pauses. A few places use the "spin the event loop" algorithm, but that actually returns to the main event loop while running code in the background which at some point queues a task to regain synchnorous control. |
| 12:09 | <hsivonen> | at least the off-the-main-thread + speculation move made the parser less unhappy with nested loops |
| 12:09 | <Hixie> | hsivonen: basically i fork off subthreads, and then queue a continuation later. |
| 12:10 | <Hixie> | dunno what xhr does |
| 12:10 | <hsivonen> | Hixie: pause and subthread sound like not matching reality |
| 12:10 | <hsivonen> | in the implementation sense |
| 12:10 | <Hixie> | pause might not |
| 12:10 | <hsivonen> | Gecko and WebKit both do nested event loops, right? |
| 12:11 | <Hixie> | the subthread/continuation thing is functionally equivalent to a nested event loop |
| 12:11 | <othermaciej> | for sync XHR, WebKit blocks without re-entering the event loop |
| 12:11 | <othermaciej> | (I think that's how it currently works anyway) |
| 12:12 | <hsivonen> | anyway, I think I'm going to implement the plan I mentioned |
| 12:12 | <hsivonen> | that is, prevent document.write if something happens to be devious enough to cause scripts to run as a side effect of the tree op flush (other than </script>) |
| 12:13 | hsivonen | wonders who came up with the synchronous SVG load event |
| 12:13 | <hsivonen> | don't we have some ground rules against stuff like that? |
| 12:14 | <remysharp> | gsnedders|work: am I right in saying that <header> doesn't affect the outline at all (I couldn't find a ref in the spec) |
| 12:15 | <gsnedders|work> | remysharp: Correct |
| 12:16 | <remysharp> | gsnedders|work: is there any reason why I can't use it to wrap the heading of a figure? (aside from the validation) |
| 12:16 | <gsnedders|work> | Don't ask me, I just wrote the impl :P |
| 12:16 | <remysharp> | :) |
| 12:17 | <remysharp> | Hixie: to you then I guess, is there any reason why I shouldn't wrap my figure heading in <header> (aside from the current validation rules) |
| 12:18 | <remysharp> | Lachy suggested some time ago "that in the future User Agents may treat the header element properly" - but I'm not sure what that means |
| 12:20 | <Lachy> | when did I say that, and in what context? |
| 12:22 | <gsnedders|work> | Context is overrrated. |
| 12:23 | <remysharp> | Lachy: sorry, some time ago, and it may be wrong, I'd be happy for you to say you didn't then I'm just waiting for the argument against using header :) |
| 12:23 | <remysharp> | context was with respect to finding an alternative to using legend in details and figure |
| 12:26 | <annevk2> | othermaciej, that's how I specced it for XHR |
| 12:27 | <annevk2> | othermaciej, you are supposed to one event at the end of the request, but that's it |
| 12:27 | <annevk2> | dispatch/\ |
| 12:27 | <Hixie> | remysharp: it'd be ambiguous with content that is allowed as the content of the element |
| 12:29 | <Lachy> | remysharp, I don't remember saying it. I might have, but it's difficult to know what I meant by it if I did without reading it in full context |
| 12:29 | <remysharp> | Hixie: such as? or rather are you saying that it shouldn't be a heading but a caption or label (though I'm not saying those elements are appropriate) |
| 12:29 | <remysharp> | Lachy: no worries - let's say for argument's sake you didn't say anything. |
| 12:29 | <remysharp> | :) |
| 12:30 | <Hixie> | remysharp: <figure> <dt> bla bla <dd> <header> foo </header> baz </figure> |
| 12:31 | <remysharp> | Hixie: I meant as a replacement to ditch the dt/dd proposal |
| 12:31 | <remysharp> | <figure> <header>My figure</header> <img src="..."></figure> |
| 12:31 | <annevk2> | Gecko does something wrong with sync XHR to not block UI or something but that caused side effects they haven't fixed |
| 12:31 | <daedb> | <header> would be very awkward for captions below the content |
| 12:32 | <remysharp> | daedb: why, it's the heading to the content, it doesn't matter if it's top, left, bottom does it? |
| 12:33 | <jgraham> | Yeah there is nothing in principle wrong with header except that in a different context it means something quite different and, as an english word, doesn't quite fit |
| 12:33 | <remysharp> | neither does article, but it's still being used for "interactive widgets" |
| 12:34 | <remysharp> | currently it's down to the spec to define it's use, just as the word article is being stretched to cover different meanings, header can quite easily be seen as the "heading to the content" - be it above or below |
| 12:35 | <daedb> | remysharp: header as a word is fairly strongly associated with top positioning, at least in my mind... using it for a caption bottom just feels odd |
| 12:35 | <remysharp> | daedb: and article? |
| 12:35 | <gsnedders|work> | Hixie: Still hasn't worked, guess the issue is at the Opera end |
| 12:35 | <Lachy> | I still need to catch up on about 1000 public-html/whatwg e-mails and spec changes after being away for a week, but does the spec now use <header> for captions, or is that just a proposal? |
| 12:35 | <remysharp> | Lachy: that's me proposing |
| 12:36 | <Hixie> | remysharp: i understood what you were proposing |
| 12:36 | <daedb> | remysharp: What about it? Completely separate issue. |
| 12:36 | <remysharp> | Lachy: because the dt/dd breaks IE, hard. |
| 12:36 | <gsnedders|work> | Lachy: I still need to _recieve_ all of the Sep/Oct emaiols :P |
| 12:36 | <gsnedders|work> | *Emails |
| 12:36 | <Hixie> | remysharp: i'm saying <header> is valid figure content, so it'd be ambiguous if we used it for the legend also |
| 12:37 | <Lachy> | yeah, dt/dd sucks just as badly as legend, and I never liked it being used for figure. |
| 12:37 | <remysharp> | Hixie: but so is dt in the content of figure or details |
| 12:37 | <Lachy> | it was ok for details, but still sucks for compat |
| 12:38 | <remysharp> | Lachy: I wrote up Dean Edwards findings yesterday: http://html5doctor.com/dd-details-wrong-again/ - it doesn't work for either details or figure |
| 12:38 | <Hixie> | remysharp: how so? |
| 12:39 | <remysharp> | Hixie: you're saying that using <header> is ambiguous if used as the caption/legend in figure because it can appear in the content - is that correct? |
| 12:40 | <remysharp> | Hixie: if so, currently the solution is to use a dt as the caption/legend, which can equally appear in the contents |
| 12:40 | <remysharp> | Hixie: in fact the example for detail actually includes it - |
| 12:41 | <remysharp> | how is that any less ambiguous? |
| 12:41 | <daedb> | dd acts as a wrapper around all the content, which removes ambiguity |
| 12:41 | <remysharp> | okay, go back to when legend was being used in the spec |
| 12:42 | <remysharp> | sorry, you'll give the same argument |
| 12:42 | <remysharp> | The styling rules that the spec has states how it should be treated though, wasn't it something like details > legend:first-child |
| 12:44 | <Hixie> | remysharp: how can it appear in the contents? i don't follow |
| 12:45 | <Hixie> | remysharp: in the spec now, only <dt> and <dd> can appear as children of <figure> |
| 12:45 | <Hixie> | remysharp: when we used <legend>, <legend> wasn't allowed in <figure> except as the legend. |
| 12:46 | <remysharp> | Hixie: Could I not use it in details, by way of having advanced search fields? |
| 12:46 | <Hixie> | remysharp: not as a child, no |
| 12:46 | <Hixie> | remysharp: as a descendant, sure, but that's fine |
| 12:46 | <Hixie> | remysharp: no ambiguity there |
| 12:47 | <smaug> | is it just my browser, or is there something wrong with html5 draft styling. The page looks strange |
| 12:47 | <remysharp> | I can see what you're saying, but you've hit the exact same problem with dd as we did with legend. They both expect to be children of some specific element, therefore the styling goes to crap (dd only in IE, but IE is obviously important) |
| 12:49 | <Hixie> | remysharp: at this point i'm basically this ->||<- close to just dropping the elements altogether and waiting until the parser is more widely deployed. |
| 12:49 | <Hixie> | that way we can go back to <legend> |
| 12:49 | <remysharp> | Don't the same kind of problems also apply to <caption> which is why it's not a decent candidate to solve this problem |
| 12:50 | <Hixie> | <caption> won't ever parse right |
| 12:50 | <Hixie> | <legend> and <dt>/<dd> will parse right in html5 parsers |
| 12:50 | <remysharp> | Hixie: I know, you're that close, and myself and others really want to get our hands on these elements |
| 12:50 | <daedb> | I don't want <figure> dropped, it's actually one of my favourite new elements... don't really care much about <details> |
| 12:50 | <Hixie> | just use <div> |
| 13:01 | <remysharp> | so here's the options: 1) repurpose /another/ element that can only be a child of some other element. Chances are there will be similar rendering issues. 2) repurpose an existing element or repurpose a new HTML5 element, both cause ambiguity issues. 3) create another heading type element to allow details & figure to remain in the spec, something like <c>, but there's a shed load of headings already. 4) Ditch them until HTML5 is supported in the |
| 13:01 | <remysharp> | majority market-share - by which point it'll be 10 years. 5) Ditch them entirely. Just use a div. |
| 13:02 | <Hixie> | 6) leave them in, and use <div> for now while you wait for the browsers to catch up, like with almost all other new features |
| 13:03 | <remysharp> | Hixie: authors will use them though, and the wonder what the hell is going on - unless you specific put that note in the spec? |
| 13:04 | <Hixie> | will authors use <style scoped> before that works in browsers? |
| 13:05 | <remysharp> | possibly not, but figure (and details?) are popular amongst authors, |
| 13:05 | <jgraham> | Hixie: I thionk that is a horribly unfair comparison |
| 13:05 | <remysharp> | they/we see the new semantics as something we want to lay our hands on right now - give better meaning to our markup |
| 13:05 | <jgraham> | <style scoped> is almost impossible to use without native support |
| 13:05 | <jgraham> | <figure> and <details> are trivial |
| 13:06 | <Hixie> | <details> only works with UA support |
| 13:06 | <remysharp> | Or JS support |
| 13:06 | <remysharp> | which is exactly what's going to happen |
| 13:06 | <jgraham> | Hixie: Not if you are willing to use js and degrade to always open |
| 13:06 | <Hixie> | <style scoped> works fine if you hack your style sheets |
| 13:06 | <jgraham> | Which I have already done a couple of times |
| 13:07 | <remysharp> | Let's be honest, if I asked your average Joe web author, who knew a little about HTML5, they'd sooner know about figure and details than they would <style scoped> |
| 13:07 | <Hixie> | i dunno about that |
| 13:08 | <jgraham> | A js library seems like a significantly lower burden to authors than using a CSS preprocessor to support <style scoped> |
| 13:08 | <Hixie> | iirc i made up <details>, whereas <style scoped> was added based on author feedback |
| 13:08 | <remysharp> | okay, but it's still an unfair comparison :) |
| 13:08 | <Hixie> | ok, <input list=""> |
| 13:08 | <Hixie> | <menu type=context> |
| 13:08 | <Hixie> | new WebSocket() |
| 13:09 | <Hixie> | draggable="" |
| 13:09 | <Hixie> | pick one |
| 13:09 | <remysharp> | you don't have to sell me on any of that stuff, I'm all over it - but the majority of authors out there are focusing on the /new/ markup |
| 13:09 | <jgraham> | I can imagine people using whichever of those can be emulated in script before browsers support them, yes |
| 13:10 | <Hixie> | you can simulate <details> and <figure> using <div> |
| 13:10 | <Hixie> | i really don't get the problem |
| 13:10 | <remysharp> | There's two types of web authors - those who know and use JS, and those who don't (particularly). |
| 13:10 | <remysharp> | I know that I can replicate details with JS |
| 13:11 | <remysharp> | but the other type of author isn't |
| 13:11 | <remysharp> | the point being is that I know that functionality isn't possible without JS, so I'm going to add it |
| 13:11 | <jgraham> | Hixie: If you change the markup you lose the native support in browsers that implement it |
| 13:11 | <remysharp> | the average html author is going to see figure, and use it |
| 13:11 | <remysharp> | unless they're told to avoid using it until X time. |
| 13:14 | <Hixie> | jgraham: if people are hacking JS to get the support, they'll likely screw up the native support anyway, to the point where UAs can't ship native support |
| 13:14 | gsnedders|work | blinks |
| 13:14 | <gsnedders|work> | I just got a WHATWG email! |
| 13:15 | <remysharp> | Hixie: no, because eventually there'll emerge an HTML5 JS library that uses PE to support this stuff. Just like DOM scripting libraries have done. |
| 13:15 | <Hixie> | PE? |
| 13:15 | <jgraham> | Hixie: That seems like a rather unfair assumption given that is quite a common approach with DOM |
| 13:15 | <remysharp> | Hixie: sorry, progressively enhance |
| 13:15 | <Hixie> | oh i'm sure some people will do it right |
| 13:15 | <jgraham> | And Modernizr or similar should have reasonable quality control |
| 13:16 | <remysharp> | and they'll become defacto |
| 13:16 | <remysharp> | and yep - they will be people who screw it up |
| 13:16 | <gsnedders|work> | There are plenty of badly written DOM libraries that are widely used that break |
| 13:16 | <remysharp> | but we're talking about the majority |
| 13:16 | <gsnedders|work> | jQuery Validation until recently broke if you implemented HTML 5 forms or WF2 |
| 13:20 | <remysharp> | gsnedders|work: so the point being is that people still screw it up even when following directions - i.e. use this library - |
| 13:20 | <annevk2> | another problem with the current alternative style sheet text is that it assumes sync loading |
| 13:20 | <Hixie> | remysharp: no, we're talking about enough to break enough pages that browsers can't deploy. That can be as little as 0.2% or less, in practice. |
| 13:20 | <remysharp> | exactly the same thing will happen when new authors read that they can use details and figure with dd |
| 13:21 | <annevk2> | e.g. if you get a Default-Style after some Link headers it is very unlikely you even know that those Link headers will become style sheet objects until quite a bit later |
| 13:21 | <Hixie> | annevk2: when you get tired of trying to get CSSOM working, encodings'll be waiting for you. Isn't your life fun? :-D |
| 13:21 | <remysharp> | but figure & dd can be styled, but it screws up styling on other elements |
| 13:21 | <remysharp> | and that's in IE |
| 13:21 | <remysharp> | which is a lot more than 0.2% |
| 13:21 | <Hixie> | annevk2: (seriously though, these are really important things, so thanks a ton for working on them.) |
| 13:21 | <annevk2> | Hixie, I appreciate your morale support |
| 13:21 | <jgraham> | Hixie: You are fine as long as someone with notable marketshare deploys before a significant legacy has built up |
| 13:21 | <annevk2> | ah, too late |
| 13:22 | <jgraham> | Which increasingly seems to be the case |
| 13:22 | <Hixie> | jgraham: yeah, that would help. |
| 13:22 | <Hixie> | anyway, 5:30am is far past my bed time |
| 13:22 | <Hixie> | nn |
| 13:22 | <annevk2> | nn |
| 13:22 | <jgraham> | Hixie: Well in the <details> case othermaciej was working on it iirc |
| 13:22 | <remysharp> | Hixie: nn - cheers. |
| 13:22 | <jgraham> | gn |
| 13:22 | <othermaciej> | I do have <details> on my todo list |
| 13:23 | <othermaciej> | I'm wondering if I should wait out the planned Change Proposal in case we end up bikeshedding the name of the label element again, but I suppose that part is easy to change |
| 14:11 | <hendry> | Anyone care to comment? http://static.webvm.net/audio/test.html |
| 14:26 | <zcorpan_> | hendry: don't nest <audio> |
| 14:26 | <zcorpan_> | hendry: use <audio><source> |
| 14:26 | <gsnedders|work> | http://www.w3.org/2001/tag/2009/10/08-minutes.html#item07 |
| 14:27 | <hsivonen> | gsnedders|work: I don't follow. Is LMM arguing against the TAG MIME Respect finding or for it? |
| 14:27 | <gsnedders|work> | I'm not sure I entirely follow either. |
| 14:31 | <hendry> | zcorpan_: ok, updated... though i am not sure about codecs for mp3/wav |
| 14:36 | <jgraham> | hsivonen: At the least I get the sense that someone is arguing against making the HTML/XHTML distinction a property of the MIME type |
| 14:37 | <hsivonen> | jgraham: that ship sailed years ago |
| 14:37 | <othermaciej> | jgraham: not everyone on the TAG has a clear view of the harbor |
| 14:38 | <jgraham> | I'm not suggesting it is a sane thing to be arguning :) |
| 14:38 | <jgraham> | *arguing |
| 14:38 | <othermaciej> | er, meant that comment for hsivonen but you guys know what I meant |
| 14:43 | <hendry> | I am little confused by audio loop http://www.whatwg.org/specs/web-apps/current-work/#attr-media-loop When combined with autoplay... should it just play continuously? |
| 14:44 | <othermaciej> | I don't think anyone suggested switching browser *behavior* for XHTML/HTML based on anything other than MIME type, but there was an argument that it's ok if some document that in some sense "is" XHTML as text/html, if processing as HTML is what you want |
| 14:44 | <othermaciej> | I think, anyway |
| 14:44 | <othermaciej> | minutes are muddled |
| 14:47 | jgraham | doesn't really understand the distinction between what a document is and how it behaves |
| 14:48 | <jgraham> | But that is some sort of philosophical position I guess |
| 14:50 | <othermaciej> | well, the spec introduces this distinction somewhat, when it says, "XML documents that use elements or attributes from the HTML namespace and that are served over the wire (e.g. by HTTP) must be sent using an XML MIME type such as application/xml or application/xhtml+xml and must not be served as text/html." |
| 14:50 | <othermaciej> | so that raises the question whether a document "is" an XML document - particularly tricky in light of polyglot document support |
| 14:51 | <othermaciej> | the spec already says separately that anything sent as text/html will be treated as HTML |
| 14:51 | <MikeSmith> | fwiw, I think the above paragraph is not necessary, or at least should be worded differently |
| 14:52 | <othermaciej> | I'm not sure I even know what that paragraph means |
| 14:52 | <MikeSmith> | it should just say that documents in the HTML namespace served with an XML mime type must conform to the XML (XHTML) syntax |
| 14:52 | <MikeSmith> | and that documents served as text/html must conform to the HTML syntax |
| 14:52 | <MikeSmith> | and leave it at that |
| 14:53 | <othermaciej> | I think the MIME type registrations included in the document might already say that |
| 14:53 | <othermaciej> | (maybe not as to XML documents served as text/xml or application/xml instead of application/xhtml+xml) |
| 14:54 | <othermaciej> | but yeah, anything that doesn't form to the HTML syntax must not be served as text/html |
| 14:54 | <othermaciej> | anything that conforms to the XML syntax either is also valid HTML (in which case you can in fact send it as text/html), or it's not, in which case it's already invalid |
| 14:54 | <Dashiva> | "Definition: A data object is an XML document if it is well-formed, as defined in this specification." - What is a data object? |
| 14:55 | <othermaciej> | the sentence I cited superficially seems to forbid serving polyglot documents as text/html, which is inconsistent with the rest of the spec |
| 14:56 | <MikeSmith> | yeah |
| 14:57 | <MikeSmith> | I don't think it's necessary for it to have that prohibition nor anything similar |
| 14:58 | <othermaciej> | I don't think it even means to prohibit that |
| 14:59 | <othermaciej> | it seems like it assumes there's some platonic sense in which something is either an HTML document or an XML document (based on author's intent? I dunno) and thus can't really be checked |
| 14:59 | <MikeSmith> | yeah, that's a good way to put it |
| 15:00 | <othermaciej> | it sort of seems like it's saying "don't serve XHTML as HTML unless you know it's not really going to get processed as XML" |
| 15:06 | <Dashiva> | "Don't serve XHTML as text/html unless it's also valid HTML" |
| 15:06 | <othermaciej> | that would be a fine thing to say |
| 15:55 | <annevk2> | so I rewrote Hixie's stuff and while less ambiguous I've no idea whether it's more clear |
| 15:56 | <annevk2> | at least it now fits in the overall picture so I guess that's progress |
| 17:16 | <AryehGregor> | "Your mail to 'whatwg' with the subject Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc. Is being held until the list moderator can review it for approval. The reason it is being held: Too many recipients to the message" |
| 17:17 | <TabAtkins> | We're not having a party in here, AryehGregor. Cut that CC list down! |
| 17:17 | <AryehGregor> | "Reply all" is standard on whatwg, right? |
| 17:17 | <TabAtkins> | Hehe, yeah. |
| 17:17 | <AryehGregor> | So am I really expected to manually prune CC lists, or is this just a misconfiguration? |
| 17:17 | <AryehGregor> | (Why does the mailing list care anyway? It only got one copy.) |
| 17:18 | <TabAtkins> | I would expect the latter. |
| 17:19 | <jgraham> | I would expect you to prune CC lists |
| 17:19 | <jgraham> | At least I tend to do that |
| 17:20 | <jgraham> | (also I assume you are aware that the moderation queue is basically /dev/null) |
| 17:20 | <AryehGregor> | Hmm, no, I wasn't. |
| 17:20 | <jgraham> | (so don't wait on Hixie to approve it or anything) |
| 17:20 | <AryehGregor> | Having to prune CC lists manually seems like an unnecessary burden. |
| 17:20 | <TabAtkins> | I don't ever prune cc lists, unless I know that another mailing list is there which isn't supposed to be cc'ed to. |
| 17:20 | <Dashiva> | Someone has to put the foot down |
| 17:21 | <Dashiva> | Otherwise the CC list will just grow into infinity |
| 17:21 | <TabAtkins> | I don't see what the problem is with that. |
| 17:22 | <Dashiva> | Sending a message does mean you want a copy of every reply that's even remotely related |
| 17:22 | <GPHemsley> | Hixie: You know that 'uk' is the Ukrainian language, right? 'ua' is not a language code. |
| 17:23 | <AryehGregor> | Well, so you can block the thread. I mean, 95% of the people on the CC list are probably on the list anyway. |
| 17:24 | <TabAtkins> | Dashiva: correct, it does mean that. |
| 17:24 | <AryehGregor> | Unless we're talking cross-posting. |
| 17:24 | <Dashiva> | TabAtkins: I was being sarcastic, I guess I failed |
| 17:24 | <TabAtkins> | Also: I don't find myself generally knowledgeable enough to know who *won't* want to receive a reply, except in the limited circumstances of stopping crossposting and in off-list conversations. |
| 17:25 | <Dashiva> | Yes, reply-all is broken by design |
| 17:25 | <Dashiva> | It should be reply-to-list-and-people-who-explicitly-say-they-want-to-be-included |
| 17:25 | <TabAtkins> | True, but we're screwed at this point. |
| 17:26 | <Dashiva> | And that's why you trim CC lists |
| 17:27 | <TabAtkins> | No it's not. I just said that I don't have enough knowledge to know who should be trimmed. |
| 17:27 | <TabAtkins> | Best case, I can remove people who I know are on the list, but that's it. |
| 17:28 | <TabAtkins> | That doesn't reduce any email volume, as they'll still receive the reply via the list, but it does reduce cc-lists, at the cost of my time. |
| 17:28 | <TabAtkins> | Which I don't find a worthwhile tradeoff. |
| 17:29 | <Dashiva> | TabAtkins: It's easy, trim everyone except the previous N posters |
| 17:29 | <TabAtkins> | That doesn't resolve the fundamental problem of me having to spend time doing this. |
| 17:30 | <AryehGregor> | Agreed. |
| 17:30 | <AryehGregor> | Now, who can reconfigure the mailing list? |
| 17:31 | <Dashiva> | Heh |
| 17:33 | <Dashiva> | The topic tends to bring out near-religious tendencies, not unlike those of resource-vs-representation |
| 17:33 | <TabAtkins> | Man, what is up with that, while we're on that topic. |
| 17:34 | <TabAtkins> | I get the idea of an abstract resource server handing out representations, but seriously, nobody actually talks about that. We just refer to resources on the web and let context disambiguate when necessary. |
| 17:34 | <AryehGregor> | I had a lengthy private argument with Julian about it. |
| 17:34 | <AryehGregor> | I was profoundly unconvinced. |
| 17:34 | <AryehGregor> | It's that whole "theoretical purity" issue, except not even conceivably useful theoretical purity in this case. |
| 17:34 | <TabAtkins> | It just feels like an architecture astronautics exercise. |
| 17:36 | <TabAtkins> | I stayed out of that discussion, luckily. I just got into it with Masinter (bad idea) about urls. |
| 17:38 | <Dashiva> | It's not practical to track which URLs are the same resource (maybe it was in the early 90s), so in practice URLs are all different |
| 17:39 | <TabAtkins> | yeah |
| 17:42 | <Dashiva> | Although even if you could, the mess would remain. When the bits change, has the resource changed or not? |
| 17:43 | <TabAtkins> | Exactly. The theoretical "resource" is an invisible, untouchable abstract idea living in a Platonic realm. You cannot answer any questions about it. |
| 17:43 | <TabAtkins> | Maybe the url is pointing to a new resource. Maybe the resource's state has changed. There's no way to tell, even theoretically, *because there isn't a difference*. |
| 17:44 | <AryehGregor> | You could define things so there's a difference, but the difference is useless in practice anyway. |
| 17:44 | <AryehGregor> | There's no way to reliably tell whether two URLs identify the same resource. |
| 17:44 | <AryehGregor> | Even on the server side. |
| 17:44 | <TabAtkins> | Yeah, the definition would be untestable and thus useless. |
| 17:45 | <TabAtkins> | You could never pass an A/B test where I get you to guess whether two urls identify the same resource or not. |
| 17:45 | <AryehGregor> | I have yet to see a statement involving resources that could not be reworded in terms of URLs, servers, and bags of bits with an increase in clarity and no significant increase in length. |
| 20:09 | <kerihenare> | Shouldn't the input type "image" be removed from HTML5? Seems that this is something that should be handled by CSS. |
| 20:12 | <gratz|home> | how would you then achieve the image map? |
| 20:13 | <TabAtkins> | Is there any particular reason to remove it? It already exists, so there's reason to keep it right there, and it's not horrifying bad. As well, as gratz|home says, it allows for imagemaps (which aren't great, but shrug). |
| 20:14 | <kerihenare> | Don't you use an <img> for Image maps? And besides, I would happily remove the <map> element. You should be using CSS their too. |
| 20:14 | <kerihenare> | *there |
| 20:17 | <kerihenare> | <center> already exists and that was removed and it's no less bad than <input type="image" /> |
| 20:17 | <annevk42> | according to you |
| 20:17 | <annevk42> | but not everyone shares that opinion |
| 20:19 | <kerihenare> | lol |
| 22:12 | <jgraham> | http://hoppipolla.co.uk/tests/document_all/document_all.html |
| 22:12 | <jgraham> | Dunno if that is useful to anyone |
| 22:17 | <jgraham> | Oh it looks like hallvord just posed something more comprehensive |
| 22:21 | <Hixie> | GPHemsley: oh. then i'd better change it back! :-) |