| 00:05 | <Dashiva> | "and do to retrieve external entities" |
| 00:05 | <Dashiva> | That's not 100% clear to me |
| 00:22 | <Lachy> | Dashiva, it was supposed to say "do not". Fixed it |
| 03:47 | <Hixie> | woah, .htaccess <files> sections override ForceType directives in lower .htaccess files |
| 03:47 | <jcranmer> | interesting use of HTML: as a stand in for programming code |
| 03:47 | <jcranmer> | < div classajkhdhsa01f0.aesf4v> |
| 03:48 | <jcranmer> | </div><div classdhnds |
| 03:48 | <jcranmer> | ? Alt ="" Height = " 190" width =" 130 |
| 03:48 | <jcranmer> | " Bori![CDATA[fboo |
| 03:49 | <Hixie> | ok i fixed the status-documentation.html thing but boy is that confusing |
| 03:49 | <Hixie> | speaking of confusing |
| 03:49 | <Hixie> | has anyone here read the RDFa processing model implementation requirements? |
| 03:50 | <Hixie> | gsnedders: i use that title="" when regenning the web-socket i-d |
| 03:50 | <Hixie> | gsnedders: and deleting the source file wouldn't really make html5 easier to read, since it would itself get regenned from the working-copy file :-P |
| 08:18 | <Hixie> | hm, feedback from yahoo |
| 08:47 | <Philip`> | Hixie: When you say "from yahoo", do you mean "from someone who is using the free Yahoo mail service"? |
| 08:58 | <Hixie> | Philip`: oh, are @yahoo e-mail addresses not yahoo employees? |
| 08:58 | <Hixie> | oh well |
| 09:03 | <Philip`> | Hixie: No, just users |
| 09:11 | <gavin_> | they use yahooinc.com for corporate addresses, I think |
| 09:24 | <jwalden> | or yahoo-inc maybe, think it's the latter but am not entirely sure |
| 09:55 | Hixie | ponders how to fix the <video> load() problem |
| 09:57 | <Hixie> | namely that <video><source src=a><source src=b></video> doesn't load src=b |
| 09:57 | <Hixie> | if src=a is broken |
| 09:57 | <Hixie> | because when b is inserted, <video> is still checking a |
| 09:58 | <Hixie> | maybe but i've no way of knowing that there is another <source> coming |
| 09:58 | <Hixie> | so i can't wait... |
| 09:58 | <Hixie> | and i can't just run the algorithm again when b comes along, because then a will be fetched twice |
| 09:59 | <Hixie> | let |
| 09:59 | <Hixie> | er |
| 09:59 | <Hixie> | i have the following events: |
| 09:59 | <Hixie> | video created |
| 09:59 | <Hixie> | video inserted |
| 09:59 | <Hixie> | source created |
| 09:59 | <Hixie> | source inserted |
| 09:59 | <Hixie> | src added/changed/removed |
| 10:06 | <Hixie> | but source could have been inserted by script before another... |
| 10:07 | <Hixie> | if script adds sources, we should probably wait for a load() |
| 10:07 | <Hixie> | but if the parser does it should probably be implied... |
| 10:07 | <Hixie> | hm, assymetry |
| 10:09 | <Philip`> | Can't you make it not start any downloads until reaching the </video>? |
| 10:09 | <Hixie> | there might not be on, consider <span><video><source></span> |
| 10:10 | <Hixie> | one |
| 10:10 | <Hixie> | or <video>EOF |
| 10:10 | <Philip`> | Oh, right |
| 10:10 | <Hixie> | it would be nice to have the parser just be like a script |
| 10:11 | <Philip`> | Can't you make it not start any downloads until the page has finished downloading and parsing and running scripts? |
| 10:11 | <Hixie> | parser inserts video (which might have a src), then inserts sources |
| 10:11 | <Hixie> | we could, but the page might never finish downloading |
| 10:11 | <Hixie> | consider an infinite iframe used for "comet"-like stuff which includes both <script> and <audio> elements |
| 10:13 | <Philip`> | Can't you make it not start any downloads until either reaching the </video> or until the page has finished downloading and parsing and running scripts, whichever comes earliest? |
| 10:14 | <Hixie> | we could but that's not very intuitive |
| 10:14 | <Hixie> | we're trying to make the platform less quirky, not more :-) |
| 10:14 | <Philip`> | (By "</video>" I probably mean "anything that causes the video element to be popped from the stack of open elements", if I remember the parser correctly) |
| 10:14 | <Hixie> | there's no real good place to hook into the parser to do that currently |
| 10:15 | <Hixie> | and i'd really rather not do anything in the parser |
| 10:15 | <Hixie> | <script> has proven that to be a nightmare |
| 10:15 | <Hixie> | it also gets really complicated to redefine it for xml |
| 10:15 | <Hixie> | and it means you can't use DOM manipulation to pretend to be a parser |
| 10:15 | <Hixie> | such as hsivonen's live dom viewer |
| 10:16 | <Hixie> | what would we want to have happen is an author inserts <video>, <source>, <source>, then moves the first source to after the second |
| 10:17 | <Philip`> | Fair enough |
| 10:19 | <Lachy> | wtf? "I develop on Win95a and 98SE [...]." -- http://www.w3.org/Bugs/Public/show_bug.cgi?id=6606 |
| 10:21 | <Lachy> | A developer is the last kind of person I'd expect to be using exremely obsolete software |
| 10:22 | Philip` | used Windows 2000 until about 2007, but using 95 today is really going a step too far |
| 10:25 | <Hixie> | the difficulty is distinguishing between <video><source><source> and <video><source><!-- long delay --><souce> |
| 10:26 | <Lachy> | I'm still using XP, it's nearly 8 years old now too, and I expect I'll still keep it around until Microsoft drops support for it or stops releasing new IE releases for it |
| 10:26 | <Hixie> | i suppose we could get rid of the list of potential media resources |
| 10:27 | <Hixie> | and just have it so that the load() algorithm, once invoked, remembers where it was, and walks down the list of <source> elements... |
| 10:27 | <Hixie> | though if one is removed... |
| 10:27 | <Hixie> | hmm |
| 10:28 | <Hixie> | this may require a rewrite of how media elements load resources |
| 10:28 | <Hixie> | but if we keep it similar enough that shouldn't be a big deal... |
| 10:28 | Hixie | stops talking to himself and switches to his editor |
| 10:30 | <Philip`> | You have an editor? |
| 10:30 | <Hixie> | emacs |
| 10:30 | <Philip`> | I thought you were doing all the work yourself, not just proxying feedback to the real editor and stealing all the credit for his work |
| 10:31 | <Hixie> | if there was someone else to blame, you can bet i'd be letting them take all the blame |
| 10:43 | <Hixie> | src="" proves problematic even with this system |
| 10:43 | <Hixie> | maybe we need a new NETWORK_ state |
| 10:44 | <Hixie> | NETWORK_EMPTY would mean that nothing is happening yet, and NETWORK_WAITING would mean that the load algorithm is active but has no resource to load |
| 10:45 | <Hixie> | and NETWORK_LOADING would mean that the algorithm is actively trying to load something |
| 10:45 | <Hixie> | NETWORK_NONE, NETWORK_WAITING, NETWORK_LOADING, NETWORK_IDLE, NETWORK_LOADED, maybe? |
| 10:45 | <Hixie> | eh i'm going to bed |
| 10:46 | <Hixie> | nn |
| 12:19 | <gsnedders> | Hixie: Do you know all cases where you actually mean @title? I've got Anolis working with data-anolis-xref locally |
| 13:23 | <yecril71> | Lachy! How do you run Internet Explorer on Wine? |
| 13:24 | <yecril71> | Wine is for third-party applications that are SDK-compliant; |
| 13:24 | <yecril71> | Microsoft�s applications are not SDK-compliant. |
| 13:25 | <yecril71> | <!DOCTYPE HTML> triggers HTML5 mode now in W3C�s validator. |
| 13:26 | <yecril71> | I wonder whether it is a good thing. |
| 13:26 | <hsivonen> | Hixie: the marked for extraction markers have a bogus month (00) |
| 13:28 | <yecril71> | krijnh! The log pages should be described as using ISO-8859-1. |
| 13:29 | <yecril71> | Internet Explorer sets the encoding to UTF-8. |
| 13:30 | <hsivonen> | yecril71: why? people are supposed to speak UTF-8 here |
| 13:32 | <yecril71> | But the logs are in ISO. |
| 13:33 | <yecril71> | 8859-1. |
| 13:33 | <yecril71> | So either fix the logs or tag them. |
| 13:33 | <hsivonen> | ‽ |
| 13:33 | <yecril71> | The headers says Content-Type: text/html;charset=utf-8 but it is not true. |
| 13:34 | <yecril71> | Your question mark caused my computer to hang for 10 s. :-) |
| 13:35 | <hsivonen> | yecril71: it seems my interrobang was correctly logged as UTF-8 and served without NCRs |
| 13:35 | <yecril71> | But look at Microsoft?s applications above. |
| 13:35 | <hsivonen> | yecril71: are you sure it isn't a problem at your end with your client speaking Windows-1252 instead of UTF-8? |
| 13:36 | <hsivonen> | krijnh: if a line doesn't decode as UTF-8, you should probably decode it as Windows-1252 for robustness. That's what irssi does. |
| 13:36 | <yecril71> | How do I change the output encoding? |
| 13:37 | <hsivonen> | yecril71: do you have irssi? |
| 13:38 | <yecril71> | I have mIRC 6.21 |
| 13:38 | <hsivonen> | then I don't know |
| 13:38 | <Philip`> | yecril71: http://www.tatanka.com.br/ies4linux/page/Main_Page |
| 13:39 | <Philip`> | hsivonen: All the status markers have bogus months (they're counting from 0 instead of 1) |
| 13:41 | <Philip`> | (Perl's localtime function is a bit unintuitive - you have to add 1 to the month and 1900 to the year) |
| 13:43 | <yecril71> | ies4linux says: �Tons of e-mails losted�. |
| 13:44 | <yecril71> | With a reflexive hyperlink to make it better :-) |
| 13:44 | <yecril71> | However, Philip`, do you happen to know what the trick behind it would be? |
| 13:45 | <Philip`> | yecril71: I don't think there's any particular trick - it's just IE, and Wine, and everything configured and packed together so it works |
| 13:46 | <Philip`> | http://appdb.winehq.org/appview.php?versionId=469 describes how to make it work in regular Wine |
| 13:49 | <yecril71> | Gosh, that page is unreadable. |
| 13:51 | <krijnh> | ? |
| 13:52 | <krijnh> | yecril71: mIRC sucks :) |
| 13:52 | <Philip`> | When I last used mIRC, there were two separate options you had to enable in order to make Unicode work |
| 13:53 | <Philip`> | With irssi I only had to set one configuration option |
| 13:53 | <Philip`> | and a command-line option |
| 13:53 | <Philip`> | and environment variables on two computers |
| 13:53 | <Philip`> | and recompile irssi |
| 13:53 | <Philip`> | but then it worked fine |
| 13:54 | <yecril71> | ROTFL |
| 13:54 | <yecril71> | krijnh! probably it does, and I am not surprised. |
| 13:57 | yecril71 | was glad to see <http://browsers.evolt.org/>; |
| 14:00 | <krijnh> | yecril71: I use mIRC as well btw ;) |
| 14:01 | <krijnh> | And I have no idea in what encoding the logfiles are saved |
| 14:04 | <yecril71> | It seems it decides on line-by-line basis between ISO-8859-1 and UTF-8. |
| 14:05 | <krijnh> | That's pretty weird |
| 14:06 | <yecril71> | Or rather CP1252 and CP65001, to be precise. |
| 14:07 | <krijnh> | Simple solution: all of you shouldn't use any weird characters :) |
| 14:08 | yecril71 | loves curly quotes and non-breaking spaces |
| 14:12 | Philip` | supposes mIRC just stores the bytes it got from the network |
| 14:12 | <Philip`> | and the network probably just transmits the bytes that clients send it |
| 14:12 | <Philip`> | so if people use stupid clients that don't send UTF-8 then you'll end up with a mixture |
| 14:13 | <yecril71> | See also <http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fkrijnhoetmer.nl%2Firc-logs%2Fwhatwg%2F20090222>; |
| 14:14 | <krijnh> | The raw log file: http://krijnhoetmer.nl/zooi/whatwg.20090222.log |
| 14:14 | <yecril71> | Oops, why did it show up in Notepad? |
| 14:15 | <yecril71> | Anyway, publishing unverified third-party content is a mortal sin :-( |
| 14:15 | <Philip`> | http://validator.nu/?doc=http%3A%2F%2Fkrijnhoetmer.nl%2Firc-logs%2Fwhatwg%2F20090222 doesn't complain about any characters |
| 14:15 | <Philip`> | (though you should use data-a and data-r :-) ) |
| 14:16 | <yecril71> | Sorry, I am unable to validate this document because on line 217 it contained one or more bytes that I cannot interpret as utf-8 |
| 14:17 | <Philip`> | yecril71: Publishing unverified third-party content is perfectly fine, as long as you escape '<' and don't serve it to draconian clients |
| 14:17 | <yecril71> | You should also make sure that the character encoding is correct. |
| 14:18 | <Philip`> | ...and as long as you set the HTTP content type so people don't go all EBCDIC on you |
| 14:18 | <Philip`> | (Er, HTTP content type charset) |
| 14:18 | <yecril71> | Right. |
| 14:18 | <Philip`> | But then it's fine :-) |
| 14:18 | <krijnh> | Sure, I could probably utf-8 encode each line |
| 14:19 | <krijnh> | Add some more overhead to each request |
| 14:21 | <krijnh> | But I think I'll stay a mortal sinner :) |
| 14:22 | Philip` | suggests not worrying about it - it's exactly what browser-side error correction is for :-) |
| 14:23 | <jgraham> | gsnedders: You here? |
| 14:23 | <krijnh> | I wasn't worrying about it for 2 years now :) |
| 14:23 | <krijnh> | (Wow, time flies!) |
| 14:24 | <hsivonen> | krijnh: not including "Now: Sun, 22 Feb 2009 15:32:21 +0100 (CET)" at the bottom of old logs would help with date-based searching |
| 14:26 | <krijnh> | Removed |
| 14:26 | Philip` | wonders if the joke "time flies like an arrow, fruit flies like a banana" can be translated into any language other than English |
| 14:27 | <krijnh> | In Dutch it would be fruitflies |
| 14:27 | <krijnh> | Err |
| 14:27 | <krijnh> | Never mind :) |
| 14:27 | <hsivonen> | krijnh: thanks |
| 14:29 | <hsivonen> | krijnh: it's still at the top. :-) It would help to have the date of the logged day there with year, month and day as tokens that Google considers separate |
| 14:29 | <krijnh> | You only mentioned the bottom of the page ;] |
| 14:30 | <krijnh> | Removed as well |
| 14:30 | <krijnh> | You mean something else than 20090222? |
| 14:30 | <krijnh> | *other |
| 14:33 | <hsivonen> | krijnh: yeah, having 2009, 02 and 22 separated by something that google considers as a word separator |
| 14:33 | <hsivonen> | e.g. hyphen or space |
| 14:33 | <Philip`> | You should be able to search with inurl:20090110..20090112 etc to get date ranges |
| 14:34 | <Philip`> | except it makes Google accuse me of being a virus or spyware |
| 14:34 | <hsivonen> | Philip`: ooh. cool. |
| 14:34 | <hsivonen> | Philip`: accuses me, too. so not cool after all |
| 14:35 | <hsivonen> | today, I started to find the first IRC log mention of a firefox build with the vendor-prefixed canvas text API, but I couldn't find it |
| 14:38 | <Philip`> | hsivonen: http://krijnhoetmer.nl/irc-logs/html-wg/20070802#l-107 |
| 14:39 | <yecril71> | How should I mark up section date? |
| 14:39 | <Philip`> | based on grepping my offline logs |
| 14:39 | <yecril71> | Section is H2, should the date be inside and styled away? |
| 14:39 | <Philip`> | yecril71: Why do you want to mark up section date? |
| 14:39 | <yecril71> | Customer�s requirement. |
| 14:39 | <yecril71> | He used to do it with TD :-) |
| 14:40 | <hsivonen> | Philip`: thanks |
| 14:40 | <Philip`> | yecril71: Why do you want to do anything more complex than putting it in <span>? |
| 14:40 | <yecril71> | The natural choice would be INS � but that is invisible. |
| 14:40 | <yecril71> | Should the SPAN be inside the H2? |
| 14:41 | <Philip`> | Is the date a part of the section's heading? |
| 14:41 | <Philip`> | e.g. should it show up in an outline view of the document? |
| 14:41 | <yecril71> | I think it should. |
| 14:42 | <yecril71> | But then, the outline view would really be a TABLE, not a list :-( |
| 15:23 | <gsnedders> | jgraham: yeah |
| 19:44 | <gsnedders> | jgraham: I guess you still aren't there |
| 19:44 | gsnedders | weeps at the loss of jgraham |
| 20:52 | <Hixie> | ok |
| 20:52 | <Hixie> | a constant that means that nothing is happening but that changing the .src will be ignored and <source> might be looked at... |
| 20:58 | <Hixie> | NETWORK_NO_SOURCE. |
| 21:14 | <erlehmann> | can someone point me to the rationale that <ins> should not cross paragraph boundaries? |
| 22:25 | jwalden | wonders if any work has been done at getting CSS support for sectioning content and heading levels |
| 22:35 | <Hixie> | jwalden: no need for css support, it can be described in css thus: http://damowmow.com/temp/sectioning.css |
| 22:35 | Hixie | ducks |
| 22:36 | <jwalden> | sectioning content elements are arbitrarily nestable, tho, but sure, if you can constrain content then it's true |
| 22:36 | <Hixie> | that css file handles the arbitrary nesting |
| 22:36 | jwalden | is actually doing that on his own site, but not to nearly that depth |
| 22:36 | <Hixie> | i'm not really suggesting browsers do this |
| 22:36 | <jwalden> | and not generically, either |
| 22:36 | <jwalden> | I know |
| 22:38 | <Hixie> | but theoretically, it means the css specs themselves don't need to change, and the browsers can implement performance hacks like :-moz-any-link |
| 22:41 | Philip` | sees that http://research.microsoft.com/apps/pubs/default.aspx?id=79655 cites Web Apps 1.0, but claims the author is a person named "W. H. A. T. W. Group" |
| 22:41 | <Philip`> | Silly LaTeX trying to initialise people's names :-( |
| 22:46 | Philip` | tries to work out what the paper is actually about |
| 23:02 | <Philip`> | Hmm, seems like the idea is to design a browser that separates each origin into its own process, with security enforced by a kernel process, only allowing cross-origin access to scripts and stylesheets (based on Content-Type) |
| 23:02 | <Philip`> | and cross-origin frames/images/plugins are handled by delegating a rectangle of the screen to another process |
| 23:04 | <Philip`> | with the idea being that same-origin-policy enforcement in current browsers is spread throughout the code and thus vulnerable to bugs, so it's more secure to have it enforced by a relatively simple kernel process instead |
| 23:06 | <Philip`> | and plugins are isolated into separate processes per origin too, and can only access resources through the kernel |
| 23:07 | <Dashiva> | So you need separate plugin instances for each origin? |
| 23:09 | <Philip`> | Yes, I think |
| 23:09 | <gsnedders> | Hixie: Oh dear lord that CSS is horrible… |
| 23:09 | <Philip`> | (Also you need to modify the plugins so they communicate through the browser kernel) |
| 23:10 | <gsnedders> | Hixie: Do we not really for sane authors need CSS support? :P |
| 23:10 | <gsnedders> | (I'm of course not implying you aren't sane…) |
| 23:12 | <Philip`> | (Strict compatibility is not a requirement - the idea is to sacrifice some compatibility for security) |
| 23:18 | <jwalden> | gsnedders: and x6 for h2-h6! :-D |
| 23:19 | <jwalden> | not to mention that h1 is really hx for the lowest x in a sectioning content element |
| 23:19 | gsnedders | does know this |
| 23:19 | gsnedders | has implemented the creating an outline algorithm |
| 23:19 | <jwalden> | at least it compresses well! |
| 23:20 | <gsnedders> | Probably the only implementation of the creating an outline algorithm that is actually used :) |
| 23:21 | <jwalden> | would be cool if html5.validator.nu had that implemented, for parity with the w3 headline generator for html4/xhtml1 |
| 23:34 | <gsnedders> | (The TOC in the spec itself is made via the outline algorithm) |