| 00:01 | <ap> | Hixie: any comment on https://bugs.webkit.org/show_bug.cgi?id=26925 ? I'm going to fix it soon, if it's ok spec-wise |
| 00:15 | <Hixie> | ap: commented. btw can you fix http://www.hixie.ch/tests/adhoc/html/offline/004.html also? |
| 00:17 | <ap> | Hixie: what's the problem with that one? I don't see a distinctive FAIL in Safari 4.0.1 on Mac |
| 00:17 | <ap> | Hixie: btw, the question was not about parsing manifests |
| 00:17 | <Hixie> | if you open it three time, it'll fail in one of the windows |
| 00:17 | <ap> | Hixie: e.g. you go to http://server/app.html#foo, and then to http://server/app.html#bar |
| 00:18 | <Hixie> | oh |
| 00:18 | <Hixie> | huh |
| 00:18 | <ap> | Hixie: alternatively, you can have manifest#foo in manifest attribute |
| 00:18 | <Hixie> | yeah that's a bug, drop an e-mail? it can just be a link to the bug |
| 00:20 | <StationsPatient> | aloha, is there a simple way to replace html entities with html5lib in python? |
| 01:45 | <Hixie> | i swear half the people in the acknowledgements are there because they pointed out that i'd misspelt occurred. |
| 01:45 | <Hixie> | how embarassing |
| 01:54 | <MikeSmith> | Hixie: you should color-code the acknowledgements and do the tag-cloud thing with names in various point sizes |
| 01:54 | <MikeSmith> | or even different fonts |
| 01:54 | <MikeSmith> | comic sans, etc. |
| 01:54 | <Hixie> | hah |
| 01:57 | <nessy> | lol |
| 02:11 | <MikeSmith> | anybody know if gecko has a Server-Sent Events implementation? |
| 02:13 | MikeSmith | finds https://bugzilla.mozilla.org/show_bug.cgi?id=338583 |
| 02:13 | <Hixie> | heycam: yt? |
| 02:13 | <heycam> | Hixie, yep |
| 02:13 | <Hixie> | heycam: http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long |
| 02:13 | <Hixie> | heycam: do you know of any way to prove that implementations are actually using ToUint32() here? |
| 02:13 | <Hixie> | rather than ToInt32() followed by clamping? |
| 02:14 | MikeSmith | notices Wellington Fernando de Macedo is same developer who's working on the WebSocket implementation |
| 02:14 | <heycam> | clamping how |
| 02:14 | <Hixie> | setting any value < 0 to 0 or something |
| 02:14 | <Hixie> | i'm trying to work out which attributes are _really_ long and which are _really_ unsigned long |
| 02:15 | <heycam> | apart from testing each one individually to see what happens when you assign or call with a negative number... |
| 02:16 | <heycam> | i guess for some it's not going to be possible to tell |
| 02:18 | <Hixie> | so, if they really do use ToUint32(), and i set them to -1, their value should be some non-zero positive number right? |
| 02:18 | <heycam> | right |
| 02:18 | <heycam> | 2**32 - 1 i think |
| 02:19 | <heycam> | hard ones to test would be e.g. HTMLOptionsCollection.length |
| 02:19 | <heycam> | you're likely to run in to memory limits i'd guess |
| 02:22 | <Hixie> | holy crap, found one -- safari <input size> really works like that |
| 02:22 | Hixie | tries IE |
| 02:26 | <Hixie> | interesting, IE throws an exception for numbers < 0 |
| 02:26 | <Hixie> | or ignores it |
| 02:27 | <Hixie> | sorry, clamps, not ignores |
| 02:27 | <Hixie> | heycam: how would you feel about changing that algorithm to use ToInt32() and then convert numbers less than 0 to 0 instead of using TUint32? |
| 02:28 | <heycam> | if you can show that that's the common behaviour, sure |
| 02:28 | <heycam> | i think i wrote it that way for consistency with how unsigned integers are handled by ES built in functions, can't remember if i did any/much testing |
| 02:32 | <Hixie> | k |
| 02:32 | <Hixie> | will write tests |
| 02:36 | <heycam> | great |
| 02:39 | <othermaciej> | Hixie, heycam: what we do in many places is convert ToInteger() (to get an integral floating point number) and then filter out NaN and out of range values |
| 02:41 | <heycam> | it would be nice if the conversion behaviour were consistent across all uses of unsigned long / unsigned short |
| 02:41 | <heycam> | othermaciej, do you know if different conversion behaviours for different attributes/operations is needed for compatibility? |
| 02:41 | <othermaciej> | heycam: no idea, we never thoroughly researched this |
| 02:45 | <othermaciej> | I guess I'm wrong, it looks like we use toInt32 for everything, which seems wrong to me |
| 02:47 | <heycam> | so infinity/nans get treated as 0 |
| 02:47 | <heycam> | ? |
| 02:52 | <Hixie> | heycam: http://www.hixie.ch/tests/adhoc/dom/webidl/attributes/001.html |
| 02:55 | <heycam> | interesting |
| 02:55 | <heycam> | so did you find any impls that do ToUint32? |
| 02:55 | <Hixie> | webkit for <input size> |
| 02:55 | <Hixie> | but that's it |
| 02:56 | <Hixie> | however, they all do random other things |
| 02:56 | <Hixie> | there's no consistency that i've found |
| 02:56 | <heycam> | i wonder what it's like for methods that take unsigned longs |
| 02:56 | <heycam> | there might be more consistency there |
| 02:57 | <Hixie> | well so it turns out that html5 is all self-contradictory about 'long' attributes |
| 02:57 | <Hixie> | which is why i'm worried about those |
| 02:57 | <Hixie> | e.g. it says various contradictory things about what reflects what |
| 02:58 | <heycam> | in terms of whether the reflected properties should clamp or whatever? |
| 02:58 | <Hixie> | i think i may convert everything to signed longs |
| 02:58 | <Hixie> | yeah |
| 02:58 | <Hixie> | it also contradicts itself on how to parse some of the attributes |
| 02:59 | <heycam> | at least if they're signed longs then you can define the conversion for negative values |
| 02:59 | <heycam> | (if you don't care about values >= 2**31) |
| 03:00 | <Hixie> | yeah |
| 03:01 | <heycam> | otoh unsigned longs seem "nicer" in some way |
| 03:01 | <heycam> | in that it would better describe the set of allowed values |
| 03:01 | <Hixie> | yeah |
| 03:02 | <heycam> | if it's safe to make all of these convert in the same way, then i'd rather they be unsigned long and to define the conversion in webidl to be whatever way is decided |
| 03:02 | <Hixie> | that is definitely ok by me |
| 03:02 | <heycam> | the "if it's safe" i don't know about. if they're all doing random other things... |
| 03:03 | <heycam> | i think something other than ToUint32 would be good |
| 03:03 | <heycam> | since it's not exactly intuitive |
| 03:03 | <Hixie> | well right now IE either throws or clamps to zero |
| 03:03 | <Hixie> | i vote for "clamps to zero" |
| 03:03 | <heycam> | and how about for NaN, Infinity, non-Numbers? |
| 03:04 | <heycam> | and non-integer numbers |
| 03:04 | <Hixie> | ToInt32() then clamp to zero |
| 03:04 | <Hixie> | they do all do TInt32() first when they don't throw |
| 03:05 | <heycam> | ok. so we'll never care about values >= 2**31? |
| 03:05 | <Hixie> | not for these i don't think |
| 03:05 | <Hixie> | i haven't tested if they handle big values |
| 03:06 | <Hixie> | but we can always do a TInt64 then clamp on both ends if necessary |
| 03:06 | <Hixie> | ToInt64 |
| 03:06 | <heycam> | testing for big values would be good |
| 03:06 | <heycam> | if it doesn't break the test |
| 03:17 | <Hixie> | http://www.hixie.ch/tests/adhoc/dom/webidl/attributes/002.html |
| 03:17 | <Hixie> | results are all over the place |
| 03:18 | <heycam> | there's a "defaults to zero" that should be "defaults to one" in the script |
| 03:19 | <heycam> | if they're all over the place, i would like "supports big numbers" to be the one we choose |
| 03:20 | <Hixie> | fine by me |
| 03:22 | <othermaciej> | what does "supports big numbers" mean? |
| 03:22 | <othermaciej> | bigger than 32-bit? |
| 03:22 | <heycam> | bigger than 31-bit |
| 03:22 | <heycam> | well, numbers that are in an unsigned 32-bit int that aren't in a signed one |
| 03:23 | <othermaciej> | so it means "unsigned 32-bit" then? |
| 03:23 | <Hixie> | it means that the conversion from Number doesn't clamp past 2**31 |
| 03:24 | <Hixie> | (test 002 isn't testing signed vs unsigned) |
| 03:24 | <Hixie> | (test 001 does that) |
| 03:24 | <Hixie> | heycam: do you want mail on this? |
| 03:25 | <heycam> | yep that'd be good thanks |
| 03:25 | <othermaciej> | do you have a test for whether conversion clamps at 2^32? |
| 03:25 | <Hixie> | no, but i'll add one |
| 03:25 | <othermaciej> | (also, I should add, a possible weird browser behavior is to wrap around instead of clamping at whatever the limit is; hopefully no browser actually does that) |
| 03:26 | <Hixie> | oh some do |
| 03:26 | <Hixie> | one also just converts 4294967290 to -2**31 |
| 03:26 | <Hixie> | in certain cases |
| 03:28 | <heycam> | the wrapping around is what is in webidl currently :) |
| 03:28 | <heycam> | due to the use of ToUint32 |
| 03:28 | <heycam> | ToInt32 would do that too, mind |
| 03:30 | <Hixie> | most browsers wrap around due to the use of ToInt32() at least in some cases |
| 03:30 | <Hixie> | webkit does it the most |
| 03:31 | <Hixie> | ok nobody seems to support >2**32 |
| 03:32 | <othermaciej> | yeah, at one point for WebKit we had the idea of using a different, non-wrapping conversion for signed values |
| 03:32 | <othermaciej> | or for unsigned, whatever |
| 03:32 | <Hixie> | IE is strangely inconsistent on this |
| 03:32 | <Hixie> | like they have different code for each attribute |
| 03:32 | <Hixie> | and it gets copied and pasted around with different changes accumulating |
| 03:33 | <othermaciej> | basically round the floating point double to the nearest integer (in the mathematical sense, not necessarily machine int), then clamp to boundaries and clean up non-finite values, then convert to appropriate machine type |
| 03:34 | <Hixie> | that seems like what webidl should say, imho |
| 03:35 | <heycam> | would cleaning up non-finite values be setting to 0? or, say, make +Infinity into the largest value in the set? |
| 03:35 | <othermaciej> | actually it should probably truncate or floor rather than round to nearest |
| 03:35 | <othermaciej> | but you get the idea |
| 03:36 | <othermaciej> | I would guess NaN should go to 0 and +/- Infinity to min/max values in the range |
| 03:37 | heycam | brb lunch |
| 03:37 | <heycam> | that sounds reasonable btw |
| 03:38 | <Hixie> | sent mail |
| 03:51 | <shepazu> | is anything being done about javascript's inability to round? |
| 03:53 | <Hixie> | inability to round? |
| 03:54 | <Hixie> | you mean the way it doesn't follow IEEE rules for rounding? |
| 03:54 | <shepazu> | when trying to round to particular significant digits (like $4,308,543.23, or such), you sometimes get rounding errors |
| 03:55 | <Hixie> | you mean using toFixed()? or something else...? |
| 03:56 | <shepazu> | Hixie: I should come up with a specific example... I kept running into it when I was doing financial planning software, a while back... I will need to look back at my notes before I can speak intelligently on it |
| 03:56 | <Hixie> | k |
| 03:56 | <Hixie> | oh you might mean the normal base-2 behaviour of floats |
| 03:56 | <shepazu> | of course, there are several IEEE rounding rules |
| 03:57 | <shepazu> | Hixie: I might mean that, I'll have to figure out what you mean :) |
| 03:59 | shepazu | reads http://en.wikipedia.org/wiki/Floating_point |
| 03:59 | <Hixie> | http://stackoverflow.com/questions/273371/real-vs-floating-point-vs-money |
| 03:59 | <Hixie> | the ES group was looking at fixing that |
| 03:59 | <Hixie> | dunno if they did or not |
| 04:00 | <Hixie> | (the problem fundamentally isn't JS, it's that you shouldn't use binary floating point numbers for fixed-point maths) |
| 04:01 | <shepazu> | Hixie, yes, that's the very problem. |
| 04:01 | <shepazu> | right, but I just want a solution :) |
| 04:01 | <Hixie> | use integers |
| 04:01 | <Hixie> | and divide by 100 everywhere |
| 04:01 | <Hixie> | or 1000, or whatever accuracy you need |
| 04:02 | <Hixie> | s/everywhere/for display/ |
| 04:02 | <shepazu> | doesn't always work, if you don't know that accuracy you need |
| 04:02 | <Hixie> | (that's basically all that a decimal type would do) |
| 04:02 | <Hixie> | why wouldn't you know the accuracy you ned? |
| 04:02 | <Hixie> | need |
| 04:02 | <shepazu> | honestly, I should look back at it... I don't recall if I finally found a solution that worked |
| 04:19 | <othermaciej> | ECMAScript does follow IEEE rounding rules |
| 04:19 | <othermaciej> | there is an ongoing proposal to add a decimal floating point type to ECMAScript |
| 04:27 | <shepazu> | othermaciej: ok, thanks |
| 05:02 | <Hixie> | othermaciej: for Math.round() it seems to not use the even-up odd-down rule (or whatever the rule is, i forget the details) but to just go towards the appropriate signed infinity |
| 05:35 | <Hixie> | (document.all == undefined) && (undefined == undefined) && (document.all != document.all) |
| 05:35 | <Hixie> | true or false? |
| 05:36 | <gavin_> | true |
| 05:37 | <Hixie> | why? :-) |
| 05:37 | <Hixie> | and in what browsers? |
| 05:38 | <gavin_> | because that's what Gecko returns and I'm horribly biased ;) |
| 05:38 | <Hixie> | biased returns false |
| 05:38 | <Hixie> | er |
| 05:38 | <Hixie> | gecko even |
| 05:39 | <Hixie> | returns false |
| 05:39 | <gavin_> | not my gecko |
| 05:39 | <gavin_> | huh, trunk differs from 3.5.x |
| 05:39 | <Hixie> | Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090709 Minefield/3.6a1pre |
| 05:39 | <Hixie> | returns false |
| 05:39 | <gavin_> | 3.5.x returns true |
| 05:39 | <Hixie> | that's ancient history :-) |
| 05:39 | <Hixie> | but that's weird |
| 05:40 | <Hixie> | why would this change |
| 05:40 | <Hixie> | and why would it ever return true?! |
| 05:40 | <gavin_> | I bet it's peterv's fault |
| 05:40 | <othermaciej> | in Safari, it's surprisingly true that document.all != document.all |
| 05:41 | <othermaciej> | I have no idea why |
| 05:41 | <Hixie> | probably a bug with the ==undefined magic |
| 05:41 | <gavin_> | (I suspect https://bugzilla.mozilla.org/show_bug.cgi?id=482788 changed that behavior) |
| 05:41 | <othermaciej> | document.all == document.all is false |
| 05:57 | <ukai> | i'm wondering we call "Web Socket", "WebSocket", "web socket" or "web sockets"... cf. https://bugs.webkit.org/show_bug.cgi?id=27206 |
| 05:58 | <Hixie> | "Web Socket" is the name of the technology, WebSocket is the name of the interface, and the other two are informal. |
| 05:58 | <Hixie> | actually "Web Sockets" is the name of the technology, iirc |
| 05:58 | <ukai> | what is the difference between "Web Socket" and "Web Sockets" ? |
| 05:58 | <Hixie> | one is singular and one is plural :-) |
| 05:59 | <Hixie> | looks like i used the plural for the API and the singular for the protocol |
| 06:00 | <ukai> | hmm, which configuration flag name do you recommend to enable the technology? |
| 06:01 | <Hixie> | *shrug* |
| 06:01 | <Hixie> | doesn't matter :-) |
| 06:01 | <ukai> | ok :-) |
| 06:04 | <MikeSmith> | ukai: I think when speaking about the feature, people just sort of naturally tend to call it "Web Sockets" (plural, with a space) |
| 06:04 | <MikeSmith> | like saying, "Server Sent Events" or whatever |
| 06:04 | <ukai> | ok, i'll use "Web Sockets" |
| 06:04 | <ukai> | thanks! |
| 06:05 | <MikeSmith> | ukai: btw, I'm really looking forward to seeing what you guys get done |
| 06:05 | <MikeSmith> | I mean on the Web Sockets work you're doing |
| 06:06 | <MikeSmith> | 楽しみに |
| 06:06 | <ukai> | you can find the work-in-progress code on http://codereview.chromium.org/155079 |
| 06:06 | <MikeSmith> | oh cool |
| 06:06 | <MikeSmith> | thanks man |
| 08:45 | <hsivonen> | Hixie: did you intend to allow spaces in itemprops? |
| 09:20 | <othermaciej> | ok, seriously? draconian parsing mode for text/html? |
| 09:20 | <othermaciej> | I can't believe this is an idea that more than one person sees favorably |
| 09:29 | <takkaria> | arrgj |
| 09:30 | <takkaria> | that's terrible |
| 09:33 | <takkaria> | can't someone just lobby their favourite browsers to include hsivonen's validator or something? |
| 09:38 | <othermaciej> | or, if you want draconian parsing in every browser likely to implement HTML5 within a decade, use XML |
| 09:38 | <takkaria> | that works too |
| 09:39 | <jgraham> | It seems like a silly idea but I assume that from the pov of the spec it would be rather simple; it would force the parser into "bail on first parse error" mode |
| 09:40 | <takkaria> | aye |
| 09:40 | <takkaria> | it does seem to be the kind of thing that should a browser toggle for authors, rather than an author toggle for users |
| 09:41 | <jgraham> | Indeed' |
| 09:42 | <gsnedders> | And then someone will use strict mode, develop with a current browser, try it with a more up to date browser, and find it breaks and blame the new browser. |
| 09:44 | <jgraham> | I thought everyone agreed that the "important financial transation" argument was bunkum |
| 09:44 | <MikeSmith> | r3401 does not affect validators? |
| 09:44 | <MikeSmith> | http://html5.org/tools/web-apps-tracker?from=3400&to=3401 |
| 09:44 | <MikeSmith> | hsivonen: ↑ |
| 09:57 | <gsnedders> | MikeSmith: It doesn't because the definition of what is valid is above that, and you don't care about parsing rules. |
| 10:02 | <hsivonen> | MikeSmith: does it require new error messages? |
| 10:08 | <MikeSmith> | hsivonen, gsnedders - I wasn't sure if that part of the spec related to integer datatype-checking or not |
| 10:10 | <MikeSmith> | Hixie: could not Web Socket protocol just use port 80? |
| 10:10 | <Philip`> | jgraham: In the context of XML in general, or HTML specifically? |
| 10:11 | <Philip`> | Maybe people will start performing financial transactions over Twitter, and if its response page aborts in the middle of a transaction tweet then you'll be wishing HTML had draconian error handling |
| 10:13 | <hsivonen> | Philip`: hehe. Mr. Safe turns to Twitter |
| 10:14 | <MikeSmith> | Mr Safe? |
| 10:15 | <hsivonen> | MikeSmith: http://www.google.com/search?q=%22Mr.+Safe%22+site%3Atbray.org |
| 10:15 | <jgraham> | Philip`: In any context. If you care about errors introduced during transmission, sign the message. If you care about the server sending a complete message add application-specific checking of the message that goes well beyond XML-well-formedness |
| 10:17 | <jgraham> | (in general if you don't trust the server code you have lost anyway afaict because a server that has a bug leading it to cut off a message like <amount>1234</amount> could just as well have a bug that led it to produce <amount>12345</amount> |
| 10:17 | <jgraham> | ) |
| 10:20 | <Philip`> | jgraham: What if you care about errors introduced during serialisation (e.g. running out of buffer space and truncating the message), after you've validated the application data and before you've done any transmission? |
| 10:21 | <Philip`> | Oh, I suppose you do something like compute a checksum of the application data (not of the serialisation) and then transmit and check that |
| 10:21 | <jgraham> | For example |
| 10:22 | <jgraham> | Plus make those errors fatal on the server |
| 10:32 | <Philip`> | "someone will use strict mode, develop with a current browser, try it with a more up to date browser, and find it breaks and blame the new browser." - it sounds like the proposal is that someone will copy-and-paste parsing=strict from wherever, develop in the latest version of IE (which doesn't support the feature), and then their users use a browser in which it fails "in-[their]-face" |
| 10:33 | <Philip`> | so you don't even need to worry about browsers changing over time, because nobody expects IE to ever implement it anyway |
| 10:35 | <hsivonen> | I wonder if I should reply to the strict mode thread |
| 10:41 | <othermaciej_> | I don't think I have anything to add to the strict mode thread except http://tinyurl.com/d5gs7f |
| 10:42 | <hsivonen> | sigh. someone made a Java impl of the public suffix list stuff but chose to offer it under a GPL-incompatible license |
| 10:44 | <hsivonen> | even though it's a port of a C++ implementation that was GPL-compatible |
| 10:46 | <Philip`> | Could you ask them to change the license? |
| 10:49 | <hsivonen> | I suppose I could |
| 10:50 | <Philip`> | <html parsing=strict parsing=loose> - I wonder if that would be a fatal error |
| 10:50 | Philip` | supposes it can't be implemented properly without reparsing anyway |
| 10:52 | <jgraham> | Philip`: I assume we would have no reparsing and just use whatever the defined attribute precedence is if it is declared multiple times on the same element |
| 10:54 | <hsivonen> | othermaciej: I agree with your assessment |
| 10:55 | <Philip`> | jgraham: But is the error fatal if it occurs after the fatality attribute has been parsed but before the element with the fatality attribute has been emitted? |
| 10:56 | <Philip`> | Actually, I suppose you could just keep a pointer to the first parse error and then fatalise it once you've found the fatality indicator |
| 11:00 | <zcorpan> | Hixie: i'd like a plain text version of html5. useful when you want to find something quickly |
| 11:00 | <zcorpan> | Hixie: like http://www.w3.org/TR/html401/html40.txt |
| 11:00 | <Philip`> | zcorpan: links -dump or something like that? |
| 11:01 | <Philip`> | or lynx or whatever it is |
| 11:01 | <zcorpan> | Philip`: yeah |
| 11:04 | <gsnedders> | zcorpan: http://gsnedders.html5.org/html5.txt |
| 11:05 | <zcorpan> | gsnedders: is it always up to date? |
| 11:06 | <gsnedders> | zcorpan: No, I could set up a cron job to do it though |
| 11:06 | <zcorpan> | gsnedders: thanks! |
| 11:07 | <zcorpan> | 22013 links |
| 11:08 | <zcorpan> | maybe the internal links are a bit useless to print out |
| 11:10 | <gsnedders> | zcorpan: OK, I set up cron to update it every day now |
| 11:11 | <zcorpan> | gsnedders: thanks |
| 11:13 | <Philip`> | gsnedders: Needs charset |
| 11:13 | <gsnedders> | Philip`: Does it? What? |
| 11:15 | <Philip`> | gsnedders: There's non-ASCII characters like © in html5.txt but no charset specified |
| 11:16 | <zcorpan> | 윤석찬 (Channy Yun) |
| 11:16 | <gsnedders> | Yeah, I saw that. |
| 11:16 | <gsnedders> | I guess the problem is at the Lynx end |
| 11:20 | <gsnedders> | Where is DanC's web addresses draft? |
| 11:22 | <gsnedders> | http://www.w3.org/html/wg/href/draft.html is the latest? |
| 11:30 | <jgraham> | It would be nice to get the text in wikipedia-style or markdown format instead |
| 11:33 | <takkaria> | http://milianw.de/projects/markdownify/ |
| 11:38 | <jgraham> | takkaria: There is also http://www.aaronsw.com/2002/html2text/ although I don't reccommend trying the online service with the HTML 5 spec |
| 11:39 | <jgraham> | It seems like it shouldn't be so difficult to implement such a tool based on html5lib but I don't have time, of course |
| 11:48 | <MikeSmith> | w3mmee |
| 11:56 | <MikeSmith> | zcorpan: might it be conceivable that sometime soon you could have bandwidth for speccing DOMParser and XMLSerializer? |
| 11:59 | <zcorpan> | MikeSmith: dunno |
| 12:03 | gsnedders | can't imagine that speccing them would take very long |
| 12:04 | <zcorpan> | i wonder if someone is willing to take over editing of web dom core |
| 12:04 | <zcorpan> | maybe someone from mozilla or apple |
| 12:06 | <MikeSmith> | zcorpan: if we could find someone willing to do that, would you be willing to commit to writing up domparser and xmlserializer? |
| 12:07 | <zcorpan> | MikeSmith: maybe :) |
| 12:07 | <MikeSmith> | OK |
| 12:09 | gsnedders | wouldn't be entirely against doing it himself |
| 12:13 | <hsivonen> | I kinda want to spec XMLSerializer and DOMParser, but I expect not to have the bandwidth for the next 6 months even if I otherwise got an OK on doing it |
| 12:13 | <gsnedders> | Why doesn't HTML5's rendering section touch on framespacing? |
| 12:18 | <zcorpan> | gsnedders: i think because gecko and webkit ignore it |
| 12:18 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/167 |
| 12:28 | <hsivonen> | Hixie: one of the permitted but obsolete doctypes triggers the quirks mode in Mac IE 5. Do you not care? |
| 12:29 | <hsivonen> | Hixie: it's the one used on ln.hixie.ch :-) |
| 13:14 | <Lachy> | hsivonen, Mac IE 5 has been obsolete for years. It's just as irrelevant now as Netscape 4. |
| 13:15 | <hsivonen> | Lachy: I guess it's OK. After all, <!DOCTYPE html> triggers the quirks mode in Netscape 6.0 |
| 13:15 | <Lachy> | wow, I didn't know that |
| 13:16 | <jgraham> | Um, Netscape 6 was irrelevant when it was current wasn't it? ;) |
| 13:16 | <hsivonen> | Lachy: http://hsivonen.iki.fi/doctype/ :-) |
| 13:17 | <gsnedders> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/168 should produce a U+FFFD element, right? |
| 13:17 | <Lachy> | jgraham, no, Netscape 6 was relevant for a short period around 2002/03 (whenever it was released) |
| 13:18 | <Lachy> | or maybe it was 2001. I can't remember. But I know I used it while I was at Uni. |
| 13:18 | <jgraham> | "relevant" in the sense that it often hung before crashing whereas sometimes it just crashed (I used it too) |
| 13:18 | <hsivonen> | jgraham: don't speak ill of the dead |
| 13:19 | <jgraham> | hsivonen: They're dead, what will they do about it? |
| 13:19 | <jgraham> | ;) |
| 13:20 | <Lachy> | jgraham, relevant in the sense that it was one of the few decent alternatives available during the early years of IE6's monopoly. |
| 13:20 | <jgraham> | (obviously the work that went in to Netscape 6 eventually led to something rather good. But that release was way way too early) |
| 13:20 | <gsnedders> | hsivonen: Am I right in thinking Fx 3.6 (with HTML5 parser) trims data at U+0000 (and inserts a U+FFFD at the end)? |
| 13:21 | <Lachy> | and by "decent", I mean "available and not IE" |
| 13:21 | <gsnedders> | Lachy: IE5/Mac was decent and was IE :P |
| 13:21 | <Lachy> | gsnedders, IE5/Mac wasn't available on Windows |
| 13:26 | <Lachy> | hsivonen, are you planning to report HTML5 parse errors through Minefield's error console? |
| 13:26 | <Lachy> | Is that possible to do? |
| 13:27 | <hsivonen> | Lachy: yes, eventually, if it doesn't poison perf and if someone else doesn't override me |
| 13:27 | <Lachy> | cool |
| 13:31 | <Lachy> | hsivonen, will that involve just parse errors, or will it effectively incorporate the HTML5 validator, and report, e.g., content model errors too? |
| 13:31 | <zcorpan> | gsnedders: no, the parser can't create elements that start with U+FFFD |
| 13:31 | <zcorpan> | gsnedders: will be a text node |
| 13:34 | <hsivonen> | Lachy: It's extremely unlikely to get content model errors from C++ code in Gecko |
| 13:34 | <hsivonen> | Lachy: I encourage people to port the above-parser layer of V.nu to JS & Firebug, though |
| 13:35 | <hsivonen> | Lachy: also, it's extremely unlikely that Gecko would whine about per-character parse errors like non-characters |
| 13:36 | <gsnedders> | zcorpan: ah, k |
| 13:37 | <gsnedders> | hsivonen: Because of perf? |
| 13:37 | <hsivonen> | gsnedders: yes |
| 13:44 | <hsivonen> | would anyone want to suggest wording for the normative warning on @summary? |
| 13:45 | <Philip`> | hsivonen: I suggest "" |
| 13:46 | <jgraham> | hsivonen: I can have a go if you like |
| 13:46 | gsnedders | puts on fair ground accent, "Come on! Have a go!" |
| 13:47 | <takkaria> | step right up, everyone's a winner |
| 13:47 | <jgraham> | s/winner/loser/ |
| 13:47 | <takkaria> | (scare quotes implied) |
| 13:48 | <hsivonen> | what about border='0'. "Hixie wants YOU to use CSS."? :-) |
| 13:48 | <gsnedders> | hsivonen: s/to use CSS.// |
| 13:48 | <gsnedders> | hsivonen: Maybe keep it in small type, actually |
| 13:51 | <hsivonen> | Hmm. It's hard to come up with credible warnings for these. |
| 13:52 | <hsivonen> | "id is a more fashionable attribute than name." maybe? |
| 13:52 | <hsivonen> | hmm. actually, that one is easier |
| 13:53 | <hsivonen> | something like "Consider putting an id attribute on the nearest container instead of using <a name> |
| 13:53 | <jgraham> | hsivonen: For name just say "Warning: the name attribute on a elements is obsolete. The id attribute should be used to serve the same purpose" |
| 13:55 | <Lachy> | "Consider summarising the purpose and structure of the table in the prose surrounding the table, rather than using the summary attribute, to make it available to more people who might find it useful." |
| 13:55 | <Dashiva> | hsivonen: For border, wouldn't it make sense to say that it becomes messy if you want to style other parts of the table with CSS? |
| 13:55 | <Lachy> | Correction: "Consider summarising the purpose and structure of the table in the surrounding prose, rather than using the summary attribute, to make it available to more people who might find it useful." |
| 13:55 | <jgraham> | hsivonen: For summary maybe something like "Warning: the summary attribute on tables is obsolete. Authours should instead provide information about the structure of complex tables in a <caption> element or in the surrounding prose usis aria to associate the description with the table (more...)" |
| 13:55 | <hsivonen> | Dashiva: border=0 is for <img> |
| 13:55 | <hsivonen> | Dashiva: to zap the hideous border in IE and Firefox |
| 13:56 | <hsivonen> | Dashiva: from copy-pasted badged |
| 13:56 | <hsivonen> | *badges |
| 13:56 | <jgraham> | where (more...) links to a page with a more detailed discussion of the issue |
| 13:56 | <jgraham> | (in general such pages would be a nice feature if you don't already have them) |
| 13:56 | <Lachy> | "Consider specifying <code>a img, img[usemap] { border: 0; } in CSS instead" |
| 13:57 | <Dashiva> | hsivonen: "Removing the image border in CSS means you don't have to think about it the next time you add an image" :) |
| 13:58 | <Lachy> | why can't Firefox and IE just remove that hideous border by default? |
| 13:59 | <Dashiva> | Then how will you know if you've visited the image link before? :) |
| 13:59 | <hsivonen> | I guess I should try writing a patch for https://bugzilla.mozilla.org/show_bug.cgi?id=452915 |
| 14:01 | <hsivonen> | hmm. I wonder if the rendering section covers this now |
| 14:20 | <hsivonen> | Hixie: did you intend to make space characters in the name attribute conforming but obsolete? |
| 14:21 | <hsivonen> | weren't spaces in name a problem? |
| 15:27 | <takkaria> | strict parsing specified in CSS? what? |
| 15:28 | <Philip`> | I think we should have <script>document.enableStrictParsing(true)</script> |
| 15:29 | <Philip`> | document.write already means there's coupling between the parser and the script engine, so it's a natural place to put it |
| 15:29 | <jgraham> | Philip`: Just writing that caused a dozen heads to explode |
| 15:30 | <Philip`> | Objective achieved! |
| 15:30 | Philip` | sees someone with User-Agent "Mozilla/5.0 (000000000; 0; 00000 000 00 0 0000; 00000; 00000000) DDDDDDDDDDDDDD DDDDDDDDDDD" |
| 17:20 | <Lachy> | yay! http://arstechnica.com/open-source/news/2009/07/ksplice-is-like-viagra-for-linux-server-uptime.ars |
| 17:21 | <Lachy> | now if only we could apply those techniques to all software updating |
| 18:02 | <Spark^> | anyone have any good ideas for a stable version of html5lib for python? i did manage to get rid of one error by doing hg update tip rather than hg update (which I assumed would be the same?) but i'm still getting an error at runtime in html5parser.py (processDocType) |
| 19:46 | <Lachy__> | Now I am completely confused by Leif's CSS based @media proposal for strict HTML parsing. It just makes no sense to me. |
| 19:49 | <tantek> | Lachy, when did strict HTML parsing ever make sense? (independent of syntax/format) |
| 19:50 | <Lachy__> | tantek, it doesn't |
| 19:53 | <hober> | Doug's use case could be addressed by a Firefox plugin / lint tool |
| 19:54 | <Lachy> | hober, that depends on exactly what Doug wants |
| 19:54 | <Lachy> | which isn't clear from his initial proposal |
| 19:56 | <hober> | I took his use case to be "developer changes markup (served as text/html), hits reload, immediately sees in his browser some indication of parse errors" |
| 19:57 | <hober> | basically, his first bullet point |
| 19:57 | <tantek> | hober - that use case is better addressed by a text editor that validates markup while you're editing, and flags errors (perhaps after waiting 1-2 seconds after you're done typing) |
| 19:57 | <hober> | totally agreed |
| 19:57 | <tantek> | no need to reload in browser to check validity |
| 19:57 | <tantek> | and much faster to have it in the editor |
| 19:57 | <hober> | [which is why I'm working on that :)] |
| 19:57 | <tantek> | heck, even use red squiggly lines like spellcheckers |
| 19:57 | <Lachy> | hober, yes, that much is clear, but what's not clear is exactly what he wants to be considered as a parse error |
| 19:58 | <hober> | Lachy: indeed. |
| 19:58 | <tantek> | to indicate invalid tags, attributes, attribute values |
| 19:58 | <Lachy> | like, does he want unquoted attributes to be considered an error (like XML), or for that to be perfectly fine like it is in normal HTML |
| 19:58 | <hober> | should it yell about a missing (or present) solidus, etc. |
| 19:58 | tantek | makes a Lazyweb request: Text editor that does HTML validity checking in realtime/inline similar to the way that modern text editors check spelling with red squiggly lines. |
| 19:59 | <hober> | tantek: assuming you're authoring xhtml5 with nxml-mode in Emacs, and plug in this stuff http://github.com/hober/html5-el/tree/master you've already got that. :) |
| 20:00 | <hober> | the line isn't squiggly, but it is red |
| 20:16 | <Philip`> | tantek: Text editor validation doesn't help when you're writing code that generates markup dynamically |
| 20:27 | <tantek> | Philip' - it does for text editors that can open an HTML file via HTTP URL. |
| 20:29 | <Philip`> | tantek: That seems less convenient than opening the HTTP URL in a web browser (with a valiator extension), and I thought the point was to make it more convenient |
| 20:30 | <tantek> | Philip` - I can see reasons for each use case. |
| 22:24 | <sicking> | Hixie, ping |
| 22:45 | <Hixie> | hsivonen: itemprops? not sure i follow your question. |
| 22:46 | <Hixie> | MikeSmith: you can use any port with websocket, but port 80 is http by default |
| 22:46 | <Hixie> | zcorpan: send mail |
| 22:47 | <Hixie> | hsivonen: i'm not especially concerned about MacIE5, no :-) |
| 22:47 | <hober> | Hixie: I think hsivonen's question is about <span item="foo"><span itemprop="bar baz">...</span></span> |
| 22:47 | <hober> | IIRC item foo has two properties, bar and baz |
| 22:48 | <Hixie> | hsivonen: send mail about spaces in name="" |
| 22:48 | <Hixie> | sicking: pong |
| 22:48 | <Hixie> | hober: if that's what he meant, then yeah, that's two properties... is the spec vague about that? |
| 22:49 | <sicking> | Hixie, so we ran into an minor issue implementing .files on drag-n-drop dataTransfer |
| 22:49 | <sicking> | Hixie, https://bugzilla.mozilla.org/show_bug.cgi?id=503598#c18 |
| 22:49 | <sicking> | Hixie, basically, we don't want to expose the files during drags |
| 22:49 | <sicking> | Hixie, but i suspect we want to expose the fact that there are files in there |
| 22:50 | <Hixie> | yeah you should only expose them ondrop |
| 22:50 | Hixie | looks at the bug |
| 22:50 | <Hixie> | (same applies to all data, not just files) |
| 22:51 | <Hixie> | if you get arun to finish his draft, i'll spec this in the html5 spec immediately |
| 22:52 | <sicking> | Hixie, i'm talking with Arun fairly often about the draft, i think a new one is on the way |
| 22:52 | <sicking> | Hixie, i don't think it'll change substantially though from previous one. Possibly introducing the local-uri thing |
| 22:53 | <sicking> | Hixie, though the lifetime still seems like a big problem to me |
| 22:54 | <sicking> | Hixie, and I think we might drop the FileDialog for now. Because ya'll are wossies ;) |
| 22:56 | <sicking> | Hixie, so in general for drag-n-drop, pages won't know at all even what type of data is in the datatransfer until the drop event? |
| 22:57 | <sicking> | Hixie, seems useful for the page to know if it will be able to handle the datatype before accepting the drop |
| 22:57 | <sicking> | Hixie, this would be orthogonal to the .files issue |
| 23:24 | <Hixie> | sicking: what's the problem with the lifetime? and i hope he'll split File into File and some base interface, too |
| 23:24 | <Hixie> | sicking: the problem with not knowing the types is an open issue with the dnd model iirc |
| 23:25 | <Dashiva> | The @parsing thing doesn't seem like a good fit for markup |
| 23:25 | <sicking> | Hixie, the problem with the life time is that I suspect Document lifetime is slightly too short |
| 23:25 | <Dashiva> | Browser error reporting, symlinks, mod_rewrite with type override... |
| 23:25 | <Hixie> | sicking: for the types, i expect we'll expose .types in all events in the future |
| 23:25 | <sicking> | Hixie, for example sticking the uri into a sessionStorage in a wizard-type page |
| 23:25 | <sicking> | Hixie, sounds good re .types |
| 23:26 | <sicking> | Hixie, we'd just need to define a type for files |
| 23:26 | <Hixie> | sicking: well we can always increase the lifetime later if we think we need to... but i think it'd be better to define a way to track the actual File or FileData objects rather than passing the URI around |
| 23:27 | <sicking> | Hixie, yeah, that's an alternative |
| 23:27 | <sicking> | Hixie, i'd still like for Storage to be able to hold File/FileData objects |
| 23:28 | <othermaciej> | I think the temporary URI design is probably not workable |
| 23:28 | <othermaciej> | I need to catch up on the discussion though |
| 23:28 | <Hixie> | othermaciej: i don't see another solution for reusing file data unless we basically add a parallel set of features across the entire platform to support File objects everywhere, and that seems painful |
| 23:28 | <othermaciej> | the problem is, you have to make sure that temporary URIs for files are unguessable, and also that they are never reused |
| 23:29 | <Hixie> | why and why? |
| 23:29 | <othermaciej> | they have to be unguessable or you have a security hole |
| 23:29 | <othermaciej> | an attacker in a different window could read the URI |
| 23:29 | <Hixie> | no, they are origin-blocked |
| 23:29 | <othermaciej> | assuming you want the URIs to be passable via postMessage for instance |
| 23:30 | <Hixie> | you'd pass the File object |
| 23:30 | <Hixie> | not the URI |
| 23:30 | <othermaciej> | in that case, they are inferior to the ability to pass a File since you can't transfer the capability |
| 23:30 | <Hixie> | correct |
| 23:30 | <Hixie> | they're not meant for passing around |
| 23:30 | <Hixie> | they're meant for plugging a File object into an <img> or <video> or some such |
| 23:30 | <othermaciej> | so it seems like adding srcFile attributes to the few HTML element interfaces that need them would be simpler |
| 23:30 | <Hixie> | or <iframe>, or CSS, or any number of things |
| 23:30 | <Hixie> | that seems unworkable to me |
| 23:31 | <Hixie> | we'd have to go through the entire platform duplicating everything, defining how one overrides the other, etc |
| 23:31 | <Hixie> | it'd be an epic disaster in terms of getting interop |
| 23:31 | <othermaciej> | (I don't think <iframe> or CSS really need them, but maybe I'm wrong) |
| 23:31 | <sicking> | Hixie, why make them origin blocked rather than unguessable? |
| 23:31 | <othermaciej> | the use case is for a preview |
| 23:32 | <sicking> | I think CSS and <iframe> is useful for things like building a HTML editor |
| 23:32 | <othermaciej> | I think giving <img>, <audio> and <video> a way to take their source from a file instead of a URI would mostly satisfy the use case |
| 23:33 | <othermaciej> | building an HTML editor would admittedly need support everywhere you can embed something |
| 23:33 | <othermaciej> | if you wanted your HTML editor to work without having to upload the resources first |
| 23:33 | <othermaciej> | but I thought the main stated use case was for previews before uploading |
| 23:34 | <othermaciej> | (any text resource you can already preview by reading the file yourself) |
| 23:34 | <othermaciej> | temporary URIs are certainly more general, but more complicated both to use and to implement for the simple preview use case |
| 23:34 | <Hixie> | sicking: because they can leak easily (e.g. referer headers) |
| 23:35 | <sicking> | Hixie, hmm... good point |
| 23:35 | <Hixie> | i don't think that temporary URIs are actually any more complicated on the long term |
| 23:35 | <Hixie> | they would be a much more localised implementation |
| 23:35 | <Hixie> | rather than spreading support all over the place, redefining processing models, etc |
| 23:36 | <othermaciej> | a more localized implementation of something way more complicated, and with tricky security implications |
| 23:36 | <sicking> | if we make the uri origin blocked then I'm not sure there are any security issues I can think of off the top of my head |
| 23:37 | <Hixie> | othermaciej: i'm not convinced it's that complicated. Why would it be that complicated? |
| 23:37 | <othermaciej> | tracking the temp URIs and implementing lifetime and origin blocking is the piece of code that would be both complicated and security-sensitive |
| 23:37 | <sicking> | Hixie, btw, doesn't data: uri suffer the same problem of leaking through referrer then? |
| 23:37 | <Hixie> | sicking: data: URIs aren't particularly secure |
| 23:38 | <sicking> | origin blocking doesn't seem that hard to implement security, granted it might be different in non-gecko browsers |
| 23:38 | <sicking> | securely |
| 23:39 | <Hixie> | othermaciej: it's just a table of ID,origin,file,document; when a document closes, you remove all the corresponding rows; whena url is dereferenced, it returns its origin and data |
| 23:39 | <Hixie> | othermaciej: unless your URI handling is especially weird, this seems relatively straightforward |
| 23:39 | <othermaciej> | Hixie: if lifetime is document but scope is origin, you have to be careful never to reuse an ID |
| 23:40 | <othermaciej> | that's one example of a potential subtle bug |
| 23:40 | <otherarun> | So the requirement is for both unguessability and origin-restriction. |
| 23:40 | <otherarun> | (the first, unguessability, may be easy -- UUID or something) |
| 23:40 | <Hixie> | othermaciej: not reusing an ID is trivial, just increase a number. |
| 23:40 | <othermaciej> | unguessability doesn't matter if they are origin restricted |
| 23:40 | <sicking> | at least not as important |
| 23:41 | <sicking> | though <img> is cross origin |
| 23:41 | <Hixie> | othermaciej: i don't really understand the not reusing an ID thing, though |
| 23:41 | <othermaciej> | Hixie: it's easier to avoid repeating if the URI doesn't have to be unguessable |
| 23:41 | sicking | didn't follow the reuse ID thing either |
| 23:41 | <Hixie> | so long as you don't create a new URI that's equal to a still-active URI, why does it matter if the ID is reused? |
| 23:41 | <othermaciej> | if you reuse an ID then it could lead to another page from the same origin that has the wrong URI reference to load the wrong file, instead of getting an error |
| 23:42 | <Hixie> | that seems like a not especially worrisome case |
| 23:42 | <Hixie> | i mean, that page could just randomly come up with a string that happens to be one that happens to be registered to its own origin too |
| 23:42 | <Hixie> | even if the ID wasn't reused |
| 23:42 | <othermaciej> | note that File references wouldn't have this problem at all, since the engine can know the lifetime of a File object but it can't know the object of a URI string |
| 23:43 | <othermaciej> | Hixie: yes, that's another flaw with the magical URI scheme |
| 23:43 | <othermaciej> | it just has much more potential for bugginess to use a magic string instead of a capability-carrying object reference |
| 23:43 | <Hixie> | i think that considering this a flaw is like considering pointers to be flawed because if you come up with a random number that happens to point into your address space, you'll dereference something instead of getting an access violation |
| 23:43 | <othermaciej> | to identify a temporary and origin-restricted resource |
| 23:44 | <othermaciej> | pointers are flawed! that's why we don't have them in ECMAScript |
| 23:44 | <Hixie> | *shrug* i'm not convinced this is a problem |
| 23:44 | <Hixie> | i mean i'm happy to make the URIs be unlikely to be reused and unlikely to clash |
| 23:44 | <Hixie> | e.g. by using UUIDs |
| 23:45 | <Hixie> | (clash with random values, i mean) |
| 23:45 | <Hixie> | but i don't think it's a problem |
| 23:46 | <othermaciej> | it's just a sloppy design, in my opinion |
| 23:46 | <Hixie> | but in any case, it's trivial to create a sequence of non-duplicate IDs that are statistically not going to clash with random numbers |
| 23:46 | <othermaciej> | not saying we can't make it work, but it will be much more bug-prone than the alternative |
| 23:46 | <Hixie> | it's far less sloppy than adding a parallel set of APIs everywhere :-) |
| 23:46 | <Hixie> | i strongly disagree with that |
| 23:46 | <Hixie> | having to add two entry points to every processing model is orders of magnitude more likely to be buggy |
| 23:46 | <Hixie> | and in weird ways that are hard to work aorund |
| 23:47 | <sebmarkbage> | Speaking of dnd... The current draft doesn't specify when pageX, clientX, screenX positions are available on the DragEvent. Gecko currently sets these to zero on the source node. It should be available on all IMHO. Is there any known security issues to this? |
| 23:47 | <othermaciej> | I doubt it. Just say srcFile always takes precedence over src, or the most recently set takes precedence, or whatever. Done. |
| 23:48 | <Hixie> | othermaciej: hah |
| 23:48 | <Hixie> | othermaciej: if only it were that easy |
| 23:48 | <othermaciej> | It would be like an hour or two of implementation work to do HTMLImageElement.srcFile and I would be confident it is right |
| 23:48 | <othermaciej> | a temporary URI vending scheme, I would expect to be finding bugs months later |
| 23:48 | <Hixie> | othermaciej: and you'd get the origin checking right for when that <img> is used with createPattern() ? |
| 23:49 | <sicking> | the downside is that we can't make it work as widely as URIs work. For example for CSS backgrounds. But i'm not sure that that is that important |
| 23:49 | <othermaciej> | sicking: yeah, that's really the main downside |
| 23:50 | <othermaciej> | Hixie: an <img> loaded from a File shouldn't have cross-origin taint, since if you have the file reference you can get the bits of the image |
| 23:50 | <othermaciej> | or at least, cross-origin taint for createPattern() would serve no useful purpose |
| 23:50 | <Hixie> | othermaciej: i'm just saying that there are FAR more complications here than first meets the eye |
| 23:50 | <Hixie> | e.g. we'd have to change the conformance rules to make sure <img> without src="" would be valid |
| 23:51 | <Hixie> | the <video> resource selection algorithm would become even more complex |
| 23:51 | <roc> | I'd prefer the URI approach from an implementation point of view. If we do the .file approach we'll have to wrap the file in a URI-like-stream internally anyway |
| 23:51 | <Hixie> | anyone relying on selectors like img[src] would have to now know they couldn't always rely on it |
| 23:52 | <othermaciej> | I'm willing to believe there may be complications, I just can't think of any (at least, none that would make it tricky for implementations) |
| 23:52 | <Hixie> | there are so many small things that would have to be defined if we added a parallel API everywhere |
| 23:52 | <othermaciej> | roc: I think the challenges with the URI approach are not so much about using it internally, but in using that URI string as a handle to the resource |
| 23:52 | <Hixie> | you also couldn't use .innerHTML suddenly, you'd have to create the markup and then poke the file in afterwards |
| 23:53 | <othermaciej> | I guess I'm not really sure it's needed everywhere |
| 23:54 | <Hixie> | i don't think it's needed everywhere, e.g. i can't think of any time i'd want to put it in <blockquote cite=""> |
| 23:54 | <roc> | Maintaining a file dictionary doesn't seem that hard, except for lifetime management. How does that work? |
| 23:54 | <othermaciej> | the only use case I've heard mentioned for that is a full-featured HTML editor that either works offline or is unwilling to upload resources before using them in editing |
| 23:54 | <roc> | Hixie: I can! |
| 23:54 | <Hixie> | roc: my proposal is to make the URIs stop resolving once their Document has been closed |
| 23:55 | sicking | has to take off |
| 23:55 | <roc> | ok |
| 23:55 | <sicking> | so far I don't feel strongly either way |
| 23:55 | <roc> | sounds good to me |
| 23:58 | <sebmarkbage> | othermaciej: It could really be all kinds of offline app scenarios such as spreadsheets or whatever. |
| 23:59 | <othermaciej> | sebmarkbage: I don't think spreadsheets need the ability to reference a temporary file from CSS to work offline |
| 23:59 | <othermaciej> | being able to read the file text, plus maybe ability to display loaded images, should be enough |