| 00:00 | <Hixie> | still unnecessary :-) |
| 00:00 | <abarth> | Hixie: can any browser actually compute the information required to "await a stable state" ? |
| 00:00 | <Hixie> | i'm sure you can find a precedent for pretty much anything |
| 00:00 | <Hixie> | abarth: how do you mean? |
| 00:00 | <abarth> | Hixie: we're trying to implement some things related to HTMLImageElement |
| 00:00 | <Hixie> | abarth: "stable state" is something you reach in the event loop. |
| 00:00 | <abarth> | Hixie: that the spec says to "await a stable state" but it seems very hard |
| 00:00 | <Hixie> | abarth: nothing to compute |
| 00:01 | <abarth> | what does "nothing to compute" mean? |
| 00:01 | <abarth> | there are always things scheduled in the event loop |
| 00:01 | <Hixie> | you don't have to compute anything to reach a stable state |
| 00:01 | <Hixie> | you just follow the loop processing model and it tells you when you're supposed to offer a stable state |
| 00:01 | <Hixie> | (which is basically any time you run microtasks) |
| 00:01 | <Hixie> | (but see the spec for specifics) |
| 00:02 | <abarth> | maybe I misunderstand the spec |
| 00:02 | <abarth> | but if there's an algorithm in the spec that spins the event loop |
| 00:02 | <abarth> | then isn't the stable state delayed until that algorithm completes? |
| 00:03 | <Hixie> | "provide a stable state" happens on step 8 of the event loop. |
| 00:03 | <abarth> | i see that |
| 00:03 | <abarth> | http://www.whatwg.org/specs/web-apps/current-work/#spin-the-event-loop |
| 00:03 | <abarth> | but it doesn't happen after step 6 of that algorithm |
| 00:04 | <Hixie> | "spin the event loop" returns to step 4, so the stable state will happen shortly after. |
| 00:04 | <Hixie> | that is, spin the event loop's step 7 returns the event loop to step 4 |
| 00:04 | <Hixie> | and from there it's quick work to reach 8. |
| 00:04 | <Hixie> | since 4, 5, and 6 are trivial and 7 is microtasks |
| 00:05 | <abarth> | i see |
| 00:05 | <Hixie> | (there's an open bug on making stable state into a microtask) |
| 00:05 | <Hixie> | (but that would make little difference) |
| 00:05 | <abarth> | so, when you spin the event loop, you actually return to the top-level event loop in the spec |
| 00:05 | <abarth> | so, why is there a microtask checkpoint at step 6 of spinning the event loop? |
| 00:06 | <abarth> | won't we get back to the main event loop and checkpoint there? |
| 00:06 | <Hixie> | yeah, there's an open bug on that too iirc |
| 00:06 | <abarth> | basically, the person submitting the CL is trying to use the microtask checkpoints to implement stable states |
| 00:06 | <Hixie> | (basically "spin" ends the current task, goes async (resuming the event loop), and then waits for the condition to be met and posts a continuation as a task. It never actually spins anything or resumes anything directly itself.) |
| 00:06 | <abarth> | and I'm trying to figure out if they're doing it right :) |
| 00:06 | <Hixie> | abarth: foolip? |
| 00:07 | <Hixie> | abarth: it's his bug asking for me to change the spec iirc |
| 00:07 | <abarth> | https://codereview.chromium.org/200923002/ |
| 00:07 | <abarth> | cbiesinger |
| 00:07 | <abarth> | apparently HTMLImageElement waits for a stable state before kicking off the load |
| 00:07 | <Hixie> | ugh, <picture> |
| 00:07 | <Hixie> | that really is gonna cause you all kinds of trouble |
| 00:07 | <Hixie> | <source> is a bad design |
| 00:07 | <smaug____> | Hixie: how could stable state be microtask? |
| 00:07 | <Hixie> | but anyway |
| 00:07 | <smaug____> | isn't stable state between tasks |
| 00:08 | <Hixie> | smaug____: microtasks are between tasks too |
| 00:08 | <abarth> | Hixie: oh, is it only in the <picture> spec that HTMLImageElement waits? |
| 00:08 | <smaug____> | there can be several microtasks in one task |
| 00:08 | <abarth> | smaug____: in the impl, we can tell the difference between the nested checkpoints and the top-level checkpoint |
| 00:09 | <abarth> | they're triggered by different systems |
| 00:09 | <abarth> | e.g., the scripting engine versus the event loop |
| 00:09 | <Hixie> | abarth: <img> as specced does a stable state too, <picture>'s problems are bigger than that. |
| 00:09 | <Hixie> | smaug____: yeah, there can be several synchronous sections (stable state consumers) too |
| 00:09 | <Hixie> | smaug____: it's all in the bugs |
| 00:09 | <abarth> | http://www.whatwg.org/specs/web-apps/current-work/#htmlimageelement step 8 says "await a stable state" |
| 00:09 | <abarth> | he's trying to implement that |
| 00:10 | <smaug____> | but how could stable state be microtask ? |
| 00:10 | <Hixie> | smaug____: i don't understand the question. why would it be hard? |
| 00:10 | <smaug____> | I don't want to start handling stable state stuff after each event listener call |
| 00:10 | <Hixie> | abarth: right |
| 00:10 | <Hixie> | abarth: you really want to coordinate with foolip (philipj). He's doing this stuff in blink. |
| 00:10 | <Hixie> | smaug____: comment on the relevant bug :-) |
| 00:11 | <smaug____> | which one is the relevant bug |
| 00:12 | <abarth> | Hixie: yes, he's CCed |
| 00:12 | <abarth> | Hixie: what is the underlying problem that waiting for a stable state here is solving? |
| 00:12 | <smaug____> | ah, https://www.w3.org/Bugs/Public/show_bug.cgi?id=24724 |
| 00:13 | <Hixie> | abarth: not wanting to do redundant work when a script modifies an attribute several times in a row |
| 00:13 | <Hixie> | smaug____: that's the one |
| 00:13 | <abarth> | Hixie: we sometimes load images synchronously out of the cache to avoid trashing layout |
| 00:13 | <Hixie> | smaug____: you found it faster than me :-) |
| 00:13 | <abarth> | because image width / height is an input to layout |
| 00:13 | <Hixie> | abarth: yeah, that's specced too iirc |
| 00:13 | <Hixie> | abarth: though the img loading model needs updating to handle the two-image thing, there's a bug on that too |
| 00:14 | <abarth> | I see the "list of available images" |
| 00:14 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=24958 is the bug iirc |
| 00:16 | <abarth> | Hixie: thanks for the info |
| 00:17 | <Hixie> | sorry i can't be more helpful, not sure what to tell you :-) |
| 00:17 | <Hixie> | i really would highly encourage you to push back on a multi-element image-loading feature |
| 00:17 | <Hixie> | it's a world of pain waiting for you |
| 00:22 | <a-ja> | <picture><img srcset> + negotiation <== sounds like fun |
| 00:25 | <TabAtkins> | Ah, I didn't realize I had been volunteered to give a lightning talk at Extensible Web Summit. |
| 00:25 | <TabAtkins> | That's fine, but I would have liked to be told by someone other than a Lanyrd update email. |
| 00:26 | <Hixie> | uh |
| 00:26 | <Hixie> | that's "nice" of them |
| 00:36 | <TabAtkins> | At least it's just a lightning talk, not a full-session talk. |
| 00:36 | <TabAtkins> | I can do a lightning talk with 5 minutes prep. |
| 02:53 | <JosephSilber> | Is there no way to prevent input elements from streching their parent td? |
| 04:14 | <Rastus_Vernon> | Aaaah, what is this? http://dev.w3.org/csswg/css-sizing/ |
| 06:33 | <Ms2ger> | I guess still half an hour left of April Fools |
| 07:34 | <zcorpan> | Hixie: it would be useful if you could be more specific about the problems with <picture>, maybe if you could read and review the current spec http://picture.responsiveimages.org/ (it's far from the same spec it was a year ago) |
| 07:34 | <sangwhan> | irccloud says i have a mention somewhere in the backlog but manual searching seems to disagree |
| 07:35 | <zcorpan> | Hixie: i think you're the only one at the moment pushing back |
| 07:35 | sangwhan | was hoping TabAtkins would have had a answer about prefixing |
| 12:06 | <yoav> | SimonSapin & TabAtkins: If you guys are around. I've got a question regarding http://dev.w3.org/csswg/css-syntax/#consume-a-string-token0 |
| 12:08 | <yoav> | If I understand correctly, under reverse solidus, the "if the stream starts with a valid escape" part is not needed |
| 12:08 | <yoav> | Is that correct? |
| 12:22 | <zcorpan> | can someone get rid of that stylesheet by now? |
| 12:23 | <jgraham> | zcorpan: The April Fools joke was actually that you thought it was only for a day |
| 12:34 | <yoav> | jgraham :D |
| 12:35 | <zcorpan> | instead it will get worse every day. in a few hours the text will start following the cursor |
| 12:36 | <jgraham> | Nah, Bert would never approve the use of javascript |
| 12:37 | <zcorpan> | then an image of Bert will also start following the cursor |
| 12:38 | <jgraham> | I think they'll go more subtle |
| 12:38 | <jgraham> | CSS Filters + Animations will be used to subtly blur the text |
| 12:38 | <jgraham> | So it will feel like it's going an and out of focus |
| 12:39 | <jgraham> | Because everyone knows that the CSS WG is actually run by a shady cabal of opticians |
| 12:39 | <jgraham> | Who else could these "Members that aren't interested in browser applications" be? |
| 13:10 | <SimonSapin> | zcorpan: done |
| 13:10 | <zcorpan> | thx |
| 13:11 | <jgraham> | You mean that Bert now follows the cursor? |
| 13:11 | <SimonSapin> | yoav: it’s needed in case you have '\' followed by a newline |
| 14:04 | <IZh> | Hi. :-) |
| 14:05 | <IZh> | How do you spell WHATWG? ;-) |
| 14:06 | <IZh> | W.H.A.T.W.G. or What W.G. or something else? |
| 14:07 | <gsnedders> | WHATWG. |
| 14:07 | <SimonSapin> | do you mean pronounce? |
| 14:07 | <IZh> | Yes. |
| 14:08 | <IZh> | Double U eight ey tee double U Gee? What double U Gee? |
| 14:08 | <gsnedders> | The latter most go for. I don't think there's any official rule, though. |
| 14:11 | <zewt> | double hat wig |
| 14:11 | <IZh> | Whatwig |
| 14:16 | <yoav> | SimonSapin: Isn't that case covered by the "Otherwise, if the next input code point is a newline, consume it." that comes right be before it? |
| 14:17 | <SimonSapin> | yoav: wait, is this for "consume a token", "consume an ident-like token", or "consume a string" ? |
| 14:18 | <yoav> | consume a string |
| 14:18 | <SimonSapin> | ah |
| 14:18 | <SimonSapin> | I was looking at the wrong place |
| 14:19 | <SimonSapin> | uhm, yes, it’s redundant now that we changed \<EOF> to not be an error |
| 14:21 | <yoav> | SimonSapin: OK, great! I'll delete that if without guilt, then :) |
| 14:26 | <SimonSapin> | yoav: Is this better? https://dvcs.w3.org/hg/csswg/raw-file/86568d6b9ce9/css-syntax/Overview.html#consume-a-string-token |
| 14:26 | <SimonSapin> | (It’ll take a few minutes to propagate to dev.w3.org.) |
| 14:27 | <yoav> | SimonSapin: That's great! |
| 15:11 | <annevk> | SimonSapin: what is evil utf-8? |
| 15:12 | <SimonSapin> | annevk: allows surrogates |
| 15:12 | <annevk> | SimonSapin: but is not CESU-8? |
| 15:12 | <SimonSapin> | it’s unclear whether CESU-8 allows lone surrogate |
| 15:13 | <SimonSapin> | I think it does not, as a consequence of UTF-16 not allowing them |
| 15:13 | <annevk> | SimonSapin: CESU-8 does not allow > U+FFFF |
| 15:13 | <annevk> | SimonSapin: that might be true in addition I suppose |
| 15:13 | <SimonSapin> | what CESU-8 does is encode non-BMP stuff as a surrogate pair, which doesn’t affect the value-space |
| 15:14 | <SimonSapin> | the point of "evil UTF-8" is to have the value space of JS strings |
| 15:15 | <SimonSapin> | I proposed it as half a joke, but interestingly roc seems to think it’s realistic https://groups.google.com/forum/#!msg/mozilla.dev.servo/1K2-Qy27e3A/Q9DWOO8Nt3EJ |
| 15:16 | <annevk> | Looks interesting |
| 15:17 | <annevk> | SimonSapin: a problem with evil utf-8 is that its value space is actually bigger |
| 15:17 | <SimonSapin> | how so? |
| 15:17 | <annevk> | SimonSapin: you can have paired surrogates as well as the actual code point |
| 15:20 | <SimonSapin> | good point |
| 15:20 | <annevk> | hsivonen: congratulations! |
| 15:20 | <SimonSapin> | so maybe it should be CESU-8 modified to allow lone surrogates |
| 15:21 | <annevk> | SimonSapin: the bad thing about that is that then you cannot just copy the input stream |
| 15:21 | <annevk> | SimonSapin: it's a tricky problem |
| 15:21 | <SimonSapin> | indeed |
| 15:22 | <SimonSapin> | would it make sense to only allow unpaired surrogates? |
| 15:22 | <annevk> | I guess you can accept that there will be two ways to represent certain code points |
| 15:22 | <SimonSapin> | that sounds bad |
| 15:22 | <SimonSapin> | makes == either wrong or hard to implement |
| 15:22 | <annevk> | It's a bit unclear to me how you can enforce that from JavaScript |
| 15:23 | <annevk> | If you can make it so that you only allow them unpaired, that would be interesting |
| 15:23 | <SimonSapin> | when decoding a JS string, turn paired surrogates to 4-bytes sequences |
| 15:24 | <annevk> | There might be some tricky edge cases, where we store strings as a list and you use += with surrogates |
| 15:25 | <annevk> | But yeah, that seems sensible, especially since it should be the edge case, over time people will use the new Unicode escapes or utf-8 directly |
| 15:27 | <SimonSapin> | I don’t understand the list thing |
| 15:28 | <SimonSapin> | but I think roc’s idea it to make this invisible from script, .charAt() would still give you UCS-2 units |
| 15:31 | <jgraham> | SimonSapin: If you have a String stored as a fragment + pointer to next fragment |
| 15:31 | <jgraham> | Which I think spidermonkey sometimes does to make append fast |
| 15:32 | <SimonSapin> | jgraham: ok, what about it? |
| 15:32 | <jgraham> | So if you had var a = low_surrogate + high_surrogate |
| 15:33 | <jgraham> | You would have a string represented as (low_surrogate, pointer) (high_surrogate, null) |
| 15:33 | <jgraham> | But semantically it would be one character |
| 15:34 | <jgraham> | (I'm not sure this would be a big problem in practice) |
| 15:37 | <annevk> | Presumably we would not use evil-utf-8 for those situations |
| 15:50 | <dglazkov> | good morning, Whatwg! |
| 16:32 | <SimonSapin> | annevk: roc’s idea seems to be to use it for everything |
| 16:32 | <annevk> | SimonSapin: you mean he'd change all string types in SpiderMonkey? I somewhat doubt that |
| 16:34 | <arunranga> | annevk, hai! I think I'd like to explore your idea of an "object list" associated with Blobs a bit more. |
| 16:34 | <SimonSapin> | https://groups.google.com/forum/#!msg/mozilla.dev.servo/1K2-Qy27e3A/Q9DWOO8Nt3EJ |
| 16:34 | <arunranga> | annevk, doesn't this mean that user agents have to analyze code beforehand? |
| 16:35 | <Hixie> | zcorpan: i went through it when srcset was first being discussed years ago. |
| 17:10 | <annevk> | arunranga: why? |
| 17:11 | <arunranga> | annevk, how is the object list constructed exactly? |
| 17:12 | <annevk> | arunranga: it's just something a blob has |
| 17:12 | <annevk> | arunranga: and other objects can use to make sure they can read the blob |
| 17:13 | <arunranga> | annevk, ok, but how do other objects get inserted into the list? How will a Blob deterministically add objects to it? |
| 17:14 | <annevk> | arunranga: the other objects would add themselves to it as part of their algorithms |
| 17:14 | <annevk> | arunranga: e.g. FormData would do it as part of serializing itself |
| 17:15 | <arunranga> | annevk, I see. So, if the Blob is CLOSED, an object can NOT add itself to the Blob's list. But pre-existing objects can still get serviced. |
| 17:16 | <arunranga> | annevk, and CLOSED blobs might be GC'd when their object lists are empty. |
| 17:16 | <annevk> | yes |
| 17:17 | <arunranga> | annevk, I think this makes sense. |
| 17:17 | arunranga | walks off to spec it |
| 17:42 | <zcorpan> | is there no way to serialize an "xml" document as html? |
| 17:43 | <zcorpan> | i thought we'd extended XMLSerializer to support that? |
| 17:45 | <gsnedders> | Create an HTML document, adopt node, then use that? |
| 18:00 | <zcorpan> | yeah, but that seems like a workaround |
| 18:01 | <zcorpan> | should be able to serialize it directly |
| 18:27 | <Hixie> | <Hixie> zcorpan: i went through it when srcset was first being discussed years ago. |
| 18:29 | <odinho> | That was different. |
| 18:30 | <SamB> | what's an "xml" document, and how does it differ from an XML document |
| 18:31 | <odinho> | Proposal was very different back then. -- The way <picture> is being done now is vastly simpler. And the most interesting/needed parts of <picture> does not use the tag at all. The 90% use case is <img> with "sizes" and "srcset" (albeit a different srcset than yours, the "w" modifier tells how wide the image is) |
| 18:31 | <zcorpan> | SamB: it doesn't differ. but it doesn't need to have come into being from parsing XML source. e.g. `new Document()` creates an XML document |
| 18:32 | <zcorpan> | SamB: whereas document.implementation.createHTMLDocument('foo') create an HTML document |
| 18:32 | <odinho> | <picture> is only metadata to an <img> that does the actual work. |
| 18:39 | <zcorpan> | Hixie: in http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html i see concern over verbosity, which i guess is still valid, but it turned out people didn't like the more terse solution with attributes on <img> |
| 18:39 | <zcorpan> | Hixie: is it just verbosity or something else? |
| 18:41 | <Hixie> | search for "multiple-element" in http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html |
| 18:42 | <Hixie> | multiple-element structures are just a nightmare to manage |
| 18:42 | <Hixie> | <video><source> and <select><option> are great examples |
| 18:42 | <Hixie> | even <object> with its impact on descendants |
| 18:42 | <SamB> | zcorpan: is that the one with the crazy attribute naming? |
| 18:42 | <Hixie> | they all suck so much |
| 18:44 | <SamB> | Hixie: nightmare from which side(s)? |
| 18:44 | <Hixie> | eveyone |
| 18:44 | <Hixie> | authors, implementors, specs |
| 18:44 | <SamB> | so, um, what's better? |
| 18:44 | <zcorpan> | Hixie: i think <picture> sucks much less than <video> |
| 18:44 | <Hixie> | SamB: anything that only involves one element, ideally one attribute. |
| 18:45 | <Hixie> | zcorpan: i'd hope we'd have a higher bar than that... |
| 18:45 | <SamB> | Hixie: that can perhaps get a bit TOO terse |
| 18:45 | <SamB> | though at least it doesn't have the crazy attribute names |
| 18:46 | <Hixie> | SamB: an attribute just takes a string, there's nothing a priori terse or verbose about it |
| 18:46 | <Hixie> | you could put an entire C++ program in there... |
| 18:46 | <SamB> | hmm |
| 18:46 | <Hixie> | or the machine code equivalent |
| 18:46 | <Hixie> | or the java equivalent |
| 18:46 | <SamB> | maybe I'm just used to not being allowed newlines between " and " |
| 18:47 | <Hixie> | just to give three examples along the line of "terse-verbose" |
| 18:47 | <zcorpan> | Hixie: sure. we tried different things and so far it seems this sucks the least, and it seems implementors are on board now |
| 18:47 | <zcorpan> | Hixie: anyway, looking at the email... |
| 18:47 | <SamB> | Hixie: which one was supposed to be the terse one |
| 18:47 | <Hixie> | zcorpan: yeah, well, i just hope someone else has to clean up the mess, cos i don't want to, that's for sure |
| 18:47 | <Ms2ger> | I'm afraid it's your job |
| 18:47 | <Hixie> | zcorpan: took me long enough to clean up <select>'s mess |
| 18:48 | <zcorpan> | Hixie: "they introduce the need for much more elaborate error handling," is handled fine in the spec, it's not really much more elaborate |
| 18:48 | <Ms2ger> | And maybe better to clean it up while it can still be changes |
| 18:48 | <Ms2ger> | changed* |
| 18:48 | <zcorpan> | Hixie: i'm pre-emptively working on having it clean :-) |
| 18:48 | <zcorpan> | Hixie: but i have to monkey-patch html which sucks |
| 18:50 | <zcorpan> | Hixie: "the processing model has to deal with changes more complicated than just "change" (what if an element is added or removed, or moved?)" - true, but it's covered. it's "just" a list of mutations that trigger an algorithm |
| 18:50 | <Hixie> | zcorpan: would you like to just own the entire <img> section? I can just have it automatically import from some doc you maintain |
| 18:50 | <hober> | zcorpan: when you say implementors are on board now, who are you referring to? |
| 18:53 | <Hixie> | zcorpan: i'm sure it's covered, but how many bugs does it have? how many edge cases have you forgotten? how many race conditions will we run into? |
| 18:53 | <Hixie> | zcorpan: we are _still_ fixing <source>, years later |
| 18:53 | <zcorpan> | hober: mozilla and blink at least are working on implementing now. not sure about apple and microsoft but i don't think there have been negative signals |
| 18:53 | <Hixie> | zcorpan: and the bugs we're finding aren't any simpler than they were at first, in fact i'd say they're much more insidious and hard to fix now than they were when we started |
| 18:54 | <Hixie> | zcorpan: if i could go back, i'd never introduce <source> |
| 18:54 | <zcorpan> | Hixie: yeah i agree about <video>'s <source>, but <picture>'s <source> isn't the same. i'm not saying there won't be bugs or that it will be easy this time, but i think i've learned the lesson about <video><source> :-) |
| 18:55 | <Hixie> | what i'm saying is that the lesson i learnt is "never again" |
| 18:55 | <Hixie> | i'm serious about the offer to just give you ownership of <img> |
| 18:56 | <Hixie> | (also, i assume there's no actual <source> in this <picture> thing? you're using <img>, right? not <source>?) |
| 18:56 | <zcorpan> | that's ok with me. let's wait a bit with that though to see how things shake out |
| 18:56 | <zcorpan> | it's <source> |
| 18:56 | <Hixie> | please don't overload <source> |
| 18:57 | <zcorpan> | what's the problem with that? <source> in itself doesn't do anything. also the attributes are different |
| 18:57 | <Hixie> | i don't want to have to deal with a bug where <source> is in a shadow dom and then grafted into a <video> while the <picture> processing model is running and then on the next microtask it's moved to a different shadow dom with an <audio> |
| 18:58 | <zcorpan> | we could call it something else i guess, but <img> would be bad for back-compat |
| 18:58 | <Hixie> | (also, you say <picture> is simpler, but you have _three_ elements?) |
| 18:58 | <zcorpan> | yeah |
| 18:58 | <Hixie> | that's not simpler. |
| 18:59 | <Hixie> | you're gonna have so much pain. |
| 18:59 | <Hixie> | anyway. please avoid interacting with other elements so we never have to worry about the case above. |
| 18:59 | <Hixie> | e.g. overloading existing elements |
| 18:59 | <Hixie> | let's keep this very self-contained |
| 19:00 | <zcorpan> | i'll file a bug about the <source> tag name, thanks |
| 19:09 | <zcorpan> | https://github.com/ResponsiveImagesCG/picture-element/issues/133 |
| 19:14 | <zcorpan> | Hixie: let's go on with the old email, in case there's something more that isn't addressed already |
| 19:15 | <zcorpan> | Hixie: "it introduces complexities in the algorithms to deal with unexpected text nodes, comment nodes, PIs, etc." - that's handled, it just skips over anything that isn't a <source> or the <img> element itself |
| 19:16 | <Hixie> | by "it's handled" in all these cases you presumably mean "i think i have handled that because it does in fact need to be handled with this design, though it wouldn't have to be if we avoided a multiple element design, and i've no idea if there won't be subtle bugs found with it later" |
| 19:16 | <zcorpan> | Hixie: "it introduces some complexity in the parser, ..." - that's handled, the algorithm starts when <img> is seen (it's <img> that does the "work"), and at that point all information is already there. anything after it is ignored |
| 19:17 | <Hixie> | what if the img is in a different document than the <picture>? |
| 19:17 | <Hixie> | does it still handle it then? |
| 19:18 | <zcorpan> | yeah then the <picture> wouldn't be a parent of the <img> so it would act like it was just the <img> and no <picture> |
| 19:19 | <Hixie> | my point is that these are questions that just don't come up if you don't do a multiple-element design |
| 19:21 | <zcorpan> | ok. yep that's true |
| 19:23 | <zcorpan> | Hixie: thanks for the feedback |
| 19:24 | <Hixie> | zcorpan: i've put markers in the spec for the part that i'm ready to hand off to you. let me know when you're ready to take it, and i'll replace that segment with a #include that merges your source in. |
| 19:24 | <Hixie> | that way you shouldn't have to worry about hooks. |
| 19:24 | <Hixie> | or monkeypatching. |
| 19:24 | <zcorpan> | ok cool |
| 19:25 | <zcorpan> | i'm ready when you've fixed my bugs :-D |
| 19:27 | <Hixie> | zcorpan: if you're going to be fiddling with that stuff anyway, might be best for you to just fix them as part of rejigging that part of the spec :-) |
| 19:27 | <zcorpan> | Hixie: sorry, not ready yet! :-P |
| 19:27 | <Hixie> | :-) |
| 19:31 | <zewt> | multi-element images is bizarre and out of place because of the two xml-like axes for data (sub-elements and attributes), html has always chosen attributes |
| 19:32 | <Hixie> | not always, but every time it's chosen elements it has been a mistake, imho. |
| 19:59 | SamB | wonders about title of this section: http://www.whatwg.org/html#the-document-object |
| 20:07 | <SamB> | I mean, why's that called Document and not HTMLDocument |
| 20:10 | SamB | somehow doubts the people responsible for the package in question are at fault WRT the non-free junk |
| 20:10 | <SamB> | er. |
| 20:10 | <SamB> | ECHAN |
| 20:11 | SamB | hates it when he does that |
| 20:27 | <smaug____> | SamB: some people think there should be only Document, not Document and HTMLDocument |
| 20:27 | <smaug____> | that doesn't match the reality too well atm |
| 20:37 | <SamB> | it would perhaps be easier to work towards that by starting with the way things are now? |
| 20:37 | <Hixie> | smaug____: it's not so much that we think there should only be one, it's that having two makes no sense in a multi-namespace world |
| 20:38 | <Hixie> | SamB: specs point to where we should be, not where we are (or were) |
| 20:41 | <smaug____> | well, it is not clear what kinds of documents XHR should return for example |
| 20:41 | <Hixie> | if there's only one kind of document, it seems pretty clear :-) |
| 20:41 | <smaug____> | adding all the legacy html stuff there doesn't make much sense |
| 20:41 | <smaug____> | since lots of those APIs would be just broken |
| 20:42 | <annevk> | So yes, somebody needs to go through the various APIs returning documents and make suggestions |
| 20:42 | <annevk> | Though I'm not super convinced that not exposing certain members here and there will actually be a large benefit |
| 20:43 | <Hixie> | i don't understand |
| 20:43 | <Hixie> | why would we want to hide certain APIs? |
| 20:43 | <Hixie> | just have them return null, etc |
| 20:43 | <Hixie> | pretty sure we already do that anyway |
| 20:43 | <Hixie> | e.g. if you hold onto a Document that's been ungrafted from browsing contexts |
| 20:44 | <annevk> | We do, we also discussed this on the WHATWG list |
| 20:44 | <Hixie> | yeah |
| 20:44 | <annevk> | I'm not sure what camp I'm in, I'd like this to move forward though |
| 20:44 | <Hixie> | i don't really understand what's controversial at this point |
| 20:44 | <Hixie> | i thought this was all long resolved |
| 20:45 | <smaug____> | really? I thought this was never resolved |
| 20:45 | <smaug____> | but was just a thing which was spec'ed to be different what implementations do |
| 20:45 | <smaug____> | but I don't have a strong opinion on this one |
| 20:48 | <SamB> | claiming that we already have everything on Document doesn't seem to have made it happen, somehow ... |
| 20:48 | <Hixie> | nobody is claiming that |
| 21:05 | SamB | wonders why nobody minds SVG being multi-element |
| 21:09 | <Hixie> | more than half the e-mails i have pending in my "canvas" folder are from adobe |
| 21:09 | <Hixie> | and the majority of the rest are from junov... |
| 21:10 | astearns | perhaps we should hire junov... |
| 21:23 | SamB | wonders how they add stuff to Java's DOM APIs ... |
| 21:37 | <SamB> | hmm, I don't suppose anyone would much care if *these* actually stayed on HTMLDocument until the heat death of the universe: http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#Document-partial |
| 21:37 | <Hixie> | HTMLDocument doesn't exist anymore according to the HTML Spec. |
| 21:38 | <Hixie> | per spec, document instanceof HTMLDocument returns true only because Document === HTMLDocument |
| 21:38 | <Hixie> | ("For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named HTMLDocument whose value is the Document interface object.") |
| 21:39 | <SamB> | hmm, that wasn't in the index |
| 21:41 | <Hixie> | which index would it be in? it's not an interface, event, element, attribute, or content model |
| 21:42 | <SamB> | it *used* to be an interface though |
| 21:43 | <Hixie> | yes |