| 02:09 | <Hixie> | man my next checkin is gonna ruffle some feathers |
| 02:09 | <Lachy> | why? |
| 02:09 | <Hixie> | i'm defining the term "xml parser" |
| 02:10 | <Lachy> | ok |
| 02:10 | <Hixie> | the text itself isn't controversial (i hope) |
| 02:10 | <Hixie> | but apparently none of the people i'm worried about complaining actually read the text |
| 02:14 | <Lachy> | I'm trying to find the definition in the spec /current-work/source, but I can't find it. |
| 02:14 | <Lachy> | I'll just wait till you check it in |
| 02:16 | <Hixie> | check /current-work/working-copy |
| 02:16 | <Hixie> | i no longer edit /source live, i edit /working-copy live instead, so that i can resume editing before the update script has finished syncing everything and so that i can them check in the previous changes without the new edits going in as well |
| 02:20 | <Lachy> | oh, so is /source copied from /working-copy and then the scripts use that copy? |
| 02:21 | <Hixie> | yeah |
| 02:22 | <Lachy> | oh, I just saw the note here is missing the ')' from the end. http://www.whatwg.org/specs/web-apps/current-work/#dynamic-markup-insertion |
| 02:22 | <Hixie> | thx |
| 02:23 | <Lachy> | "An XML parser, for the purposes of this specification, is a construct that follows the rules given in the XML specification to map a string of bytes or characters into a Document object." - doesn't seem controversial |
| 02:24 | <Hixie> | like i said, the text is fine :-) |
| 02:25 | <Lachy> | well, I guess it is controversial for those who believe an XML parser should be completely independent of the DOM and that it may not output a Document object |
| 02:28 | <Hixie> | it'll be controversial because "it defines the term xml parser!!! aaah!!!" |
| 02:32 | <Lachy> | Hixie, will attributes like name be defined, or at least listed, in the Obsolete Features section? http://www.whatwg.org/specs/web-apps/current-work/#obsolete-features |
| 02:32 | <Lachy> | I guess, since it defines some such attributes already |
| 02:33 | <Lachy> | it might be worth pointing that out to Roy |
| 02:33 | <Hixie> | i wasn't planning on making any author-facing statements in that section |
| 02:33 | <Lachy> | oh, ok |
| 02:33 | <Hixie> | i was going to keep it at the bare minimum of implementation requirements |
| 02:34 | <Lachy> | hmm, I suppose providing authoring information about obsolete features doesn't really benefit anyone |
| 02:37 | <Lachy> | I think it's bed time. Tomorrow, I want to try and make some significant progress on the authoring guide |
| 02:37 | <Hixie> | cool |
| 02:37 | <Lachy> | and finish the blog entry I started tonight about Mike's markup spec |
| 02:37 | <Lachy> | nn |
| 02:45 | <Lachy> | Hixie, wtf happened here? http://www.whatwg.org/specs/web-apps/current-work/multipage/ |
| 02:45 | <Hixie> | the spec is in a poor state right now |
| 03:13 | <Hixie> | ok |
| 03:14 | <Hixie> | if anyone wants to review http://www.whatwg.org/specs/web-apps/current-work/multipage/index-diff while i'm at dinner, that'd be great :-D |
| 06:54 | <zcorpan> | Hixie: maybe you should move the doctype stuff in xml from conformance requirements to writing xhtml documents? |
| 06:58 | <Hixie> | hm, not a bad idea |
| 09:15 | <zcorpan> | hey wait a minute. onclick etc listen for any 'click' events, not only MouseEvents? |
| 09:16 | <zcorpan> | i.e. if i dispatch a 'click' event with the wrong type, onclick will catch it |
| 09:17 | <zcorpan> | geez that makes testing a whole lot easier |
| 09:18 | <zcorpan> | i had started to set up a mapping between event names and their interface and a mapping between interfaces and the appropriate initFooEvent method |
| 09:18 | <zcorpan> | now i can drop both tables and just do createEvent('Event') and then initEvent(e, true, true, window) |
| 09:19 | <zcorpan> | wish someone told me this before |
| 09:21 | <zcorpan> | i wonder why dom events have so much indirection |
| 09:22 | <zcorpan> | (not to mention that there's initFooEventNS with another level of indirection) |
| 09:26 | <zcorpan> | Hixie: might be worth adding a note to the spec saying that the event handler attributes ignore the event's interface |
| 09:28 | <zcorpan> | Hixie: actually the spec is wrong, it says "Must be invoked whenever an abort event is targeted at or bubbles through the element or object." where "abort" is linked to a definition that states a specific interface |
| 09:28 | <zcorpan> | actually i'll just file a bug |
| 09:36 | <hsivonen> | It seems like <dialog> is more trouble than it's worth. We could say dialog is abbreviated <dl> instead. |
| 09:59 | <annevk> | it's interesting how Leif goes from not optimized for, to unfit, without explaining why |
| 10:03 | <annevk> | hsivonen, if we want to use it for chat logs as well having a different container would help |
| 10:04 | <annevk> | hsivonen, so you can allow other elements in it as well |
| 10:05 | <zcorpan> | annevk: other elements between dt and dd aren't compatible with ie's parser |
| 10:10 | <annevk> | you'd have to require closing tags |
| 10:10 | <annevk> | oh, I guess I see what you mean |
| 10:10 | <annevk> | well, hopefully IE gets a better parser in due course |
| 10:12 | <BenMillard> | it seems people just use <p> and put the speaker name somewhere near the start on the web |
| 10:12 | <BenMillard> | so I guess that's all users need |
| 10:13 | <BenMillard> | some examples: http://projectcerbera.com/web/study/2008/dialogue |
| 10:13 | <BenMillard> | oh, some use <dl> instead |
| 10:14 | <BenMillard> | uses <dl>, then stops the <dl> and uses <h4> to change scene: http://greenmethods.com/site/weblog/2001/01/whos-ojectionable/ |
| 10:15 | <BenMillard> | then starts a new <dl> after the <h4> scene change |
| 10:16 | <BenMillard> | there is no container around the dl+h4+dl sequence, so maybe stopping and starting <dl> works fine |
| 10:18 | <BenMillard> | <dl class="dialog"> with <p> and suchlike inside each <dd>: http://xhtml.com/en/web-standards/conversation-with-opera/ |
| 10:22 | <BenMillard> | zcorpan, the IRC demos now use #dfd as you suggested: http://projectcerbera.com/!dev/irc-logs/day-telecon |
| 10:22 | <BenMillard> | zcorpan, I got the chance to test it on a range of TFTs and a couple of laptops. It's much more visible on them. |
| 10:23 | <BenMillard> | zcorpan, I find it kinda funny that this huge, hot CRT from 2001 has better colouration than "high-tech" flat screens from 2008. :) |
| 10:29 | <zcorpan> | BenMillard: maybe you have a pretty low contrast set? |
| 10:29 | <zcorpan> | er |
| 10:29 | <zcorpan> | low brightness |
| 10:31 | <BenMillard> | zcorpan, the TFTs I tested were factory settings |
| 10:32 | <BenMillard> | zcorpan, just played around with contrast setting on this CRT, still great colouration |
| 10:32 | <BenMillard> | TFTs always look grubby compared to this...and yes I did make sure they weren't covered in dust first :P |
| 10:33 | <BenMillard> | the laptops were LCDs and the most modern one was better than the TFTs but still not as good as this CRT |
| 10:33 | BenMillard | hugs his screen. |
| 10:34 | <BenMillard> | zcorpan, brightness setting on this CRT is factory default. I see how lowering it makes brighter colours more distinct, though |
| 10:40 | <jgraham> | In general flat panel screens are known to have poorer colour reproduction than CRTs. Although it depends significantly on the panel tech. If you are prepared to pay say $1000 for a flat panel you can get one with good enough colour reproduction for professional print publication |
| 10:41 | <BenMillard> | jgraham, nice to know I'm not going mad, thanks. 8) |
| 10:41 | <jgraham> | Panels costing like 100 GBP use a technology that has good refresh rate (nice for games) but lousy colours |
| 10:42 | <takkaria> | apple displays also tend to have a wider colour gamut than most other TFTs |
| 10:42 | <jgraham> | See http://www.hardforum.com/showthread.php?t=1039222 for example |
| 10:49 | <BenMillard> | jgraham, enlightening. :) |
| 10:55 | <Philip`> | (Hmm, my new 'grep' takes about one minutes for 130K pages, rather than >10 minutes for the old one) |
| 10:55 | <Philip`> | (I probably ought to multithread it so it's 4x faster, which would be nice) |
| 11:05 | <jgraham> | Philip`: Is it CPU limited? |
| 11:18 | <Philip`> | jgraham: Yes |
| 11:18 | <Philip`> | jgraham: (It used to be disk limited, but now there's fewer files and they're compressed so it should all be cached in RAM) |
| 11:23 | <jgraham> | Philip`: Clearly the solution is to rewrite everything in Erlang |
| 11:24 | <Philip`> | jgraham: What advantages would that have over simply adding a ThreadPoolExecutor and a few lines of glue and a synchronized output method? :-) |
| 11:32 | <jgraham> | Philip`: It would have more magic pixie dust. |
| 11:32 | <Philip`> | jgraham: How much more magic pixie dust, as a percentage by mass? |
| 11:33 | <jgraham> | Magic pixie dust has zero mass (and therefore is ruled out as a candidate for dark matter) |
| 11:35 | <hsivonen> | Hixie: Gecko ranks kCharsetFromHintPrevDoc higher than kCharsetFromAutoDetection. |
| 11:35 | <Philip`> | jgraham: Magic pixie dust couldn't be a candidate for dark matter anyway, because it glows |
| 11:36 | <hsivonen> | Hixie: so shouldn't HTML5 have that, too, between chardet and the user-set default? |
| 12:15 | <annevk> | wow, never realized that lack of an overview of elements and attributes prevented people from reviewing the specification |
| 12:15 | <annevk> | maybe we should add them then |
| 12:26 | <zcorpan> | annevk: there's an overview at http://simon.html5.org/html5-elements |
| 12:27 | <hsivonen> | zcorpan: It's not normative! :-) |
| 12:27 | <zcorpan> | hsivonen: an overview in the spec wouldn't be normative, either |
| 12:27 | <hsivonen> | zcorpan: indeed |
| 12:28 | <hsivonen> | zcorpan: more seriously, though, I think your page should be publicized more widely |
| 12:28 | <zcorpan> | some people linked to it a few years ago |
| 12:29 | <karlcow> | http://twitter.com/karlpro/status/1158293590 |
| 12:30 | <zcorpan> | karlcow: thanks :) |
| 12:34 | <Lachy> | zcorpan, do you have a script that generates that list of elements? |
| 12:35 | <zcorpan> | Lachy: no :( |
| 12:36 | <Lachy> | ok. I could have used it since I think we need an index of elements and attributes for both the spec and authoring guide |
| 12:36 | <Lachy> | but I guess I will have to write my own one day |
| 12:39 | <zcorpan> | maybe hsivonen or Philip` have something that can be used to generate an index |
| 12:40 | <hsivonen> | I have the thingy that scrapes the spec for element-specific attributes |
| 12:42 | <zcorpan> | Hixie: should we have a dedicated exception for "too few arguments" or "wrong arguments" instead of NOT_SUPPORTED_ERR? |
| 12:45 | <annevk> | it should be fairly trivial to write a script since the element definitions are pretty consistent |
| 12:45 | <annevk> | though you might want special code for <input> |
| 12:45 | <hsivonen> | annevk: there are gotchas like the body element appearing twice |
| 12:46 | <Lachy> | I'd need a script that scrapes from the authoring guide, which is structured differently from the spec |
| 12:46 | <Lachy> | and is undergoing a major restructuring right now |
| 12:47 | <annevk> | hsivonen, that one doesn't carry the class |
| 12:47 | <annevk> | i.e. the conforming element definitions carry a class name which can be used to identify them |
| 12:47 | <hsivonen> | annevk: oh. good to know. the observation would have saved me some trouble earlier |
| 12:49 | <hsivonen> | Hixie: where does the relative order of last visited charset and frequency analysis come from? |
| 12:49 | <hsivonen> | Hixie: as far as I can tell, Gecko seems to have them the other way round |
| 13:01 | <hsivonen> | Hixie: is it intentional that charset inheritance for same-origin iframes isn't specced explicitly? |
| 13:03 | <Philip`> | karlcow: Wow, a Twitter message with a URL that's not using something like TinyURL |
| 13:04 | <Lachy> | Philip`, what twitter message? |
| 13:04 | Philip` | wonders if anyone is archiving the URL-shortening services' databases, to avoid vast swathes of links all across the web suddenly disappearing when those services shut down |
| 13:04 | <Lachy> | Philip`, I doubt it |
| 13:04 | <Philip`> | Lachy: The one karlcow wrote and linked to |
| 13:05 | <karlcow> | twitter, frienfeed thing is becoming insane, yes I had to click through 4 indirections before going to the page |
| 13:06 | <annevk> | it seems the class name is on the <dl> following the header, by the way |
| 13:06 | <annevk> | however, another difference seems to be is that the second body element header does not have <dfn> |
| 13:07 | <annevk> | the most annoying thing with twitter indirection is that when you click to expand and then click the link you still go to the fricking redirect service |
| 13:10 | <zcorpan> | Philip`: any data on the insertHTML execCommand? |
| 13:10 | <Philip`> | zcorpan: Do you have a regexp for that? |
| 13:12 | <zcorpan> | Philip`: execCommand\s*\(\s*("|')insertHTML ...maybe? |
| 13:12 | <zcorpan> | though the inserthtml part should be case insensitive |
| 13:18 | <Philip`> | zcorpan: http://philip.html5.org/data/execCommand.txt |
| 13:19 | <zcorpan> | Philip`: interesting |
| 13:19 | <Philip`> | Lots of people using the http://evil.che.lu/2006/9/25/no-more-ie6-background-flicker hack, it seems |
| 13:21 | <Philip`> | (Maybe the more advanced uses of execCommand tend to be hidden in external scripts?) |
| 13:22 | <zcorpan> | Philip`: likely |
| 13:24 | <annevk> | hmm, my extract script gets 96 elements |
| 13:24 | <zcorpan> | annevk: sub/sup? |
| 13:25 | <annevk> | hmm yeah, and mine includes <applet> ;/ |
| 13:25 | <Philip`> | Do you cope with h1-h6? |
| 13:25 | <annevk> | me? no |
| 13:26 | <annevk> | it's five lines of Python atm |
| 13:26 | <Philip`> | zcorpan: http://simon.html5.org/html5-elements seems to not cope with h1-h6 either |
| 13:27 | <annevk> | what are you implying? |
| 13:27 | <annevk> | oh, those elements |
| 13:27 | <annevk> | duh |
| 13:27 | <Philip`> | Yes :-) |
| 13:27 | <Philip`> | because they're not in the spec as individual elements |
| 13:27 | <Philip`> | so extraction scripts have to be careful to handle them properly |
| 13:28 | <zcorpan> | Philip`: oops.. i thought i had h1-h6 |
| 13:28 | <annevk> | I suppose I can add special code for the case where it ends with "elements</h4>\n" |
| 13:29 | <Philip`> | annevk: That seems an unnecessary generalisation - just do the special case "The h1, h2, h3, h4, h5, and h6 elements" |
| 13:29 | <Philip`> | Oh, except for sub and sup |
| 13:29 | <annevk> | right |
| 13:30 | <annevk> | i suppose i'll special case <div> as being the last valid element too |
| 13:33 | <zcorpan> | Philip`: fixed, thanks |
| 13:34 | <annevk> | ok, maybe h1-h6, sub and sup need to be special cased |
| 13:35 | <Lachy> | I've published a major restructured version of the authoring guide (temporarily omitting the element reference) http://dev.w3.org/html5/html-author/ |
| 13:35 | <Lachy> | This includes a new Overview section describing what the content of each section will be |
| 13:40 | <Lachy> | I'm considering renaming the guide too, since The Web Developer's Guide to HTML 5 is a little long. Possibly something like HTML 5: The Web Developer Reference (or Guide), or HTML 5: Developer's Reference |
| 13:41 | <Philip`> | The former alternative is longer than the current name |
| 13:41 | <Philip`> | The latter seems confusing since "Developer" could mean UA developer rather than web-page developer |
| 13:43 | <Lachy> | hmm, yeah. This is hard. |
| 13:44 | <annevk> | HTML 5 for Authors |
| 13:44 | <Lachy> | I need the name to be short, easy to abbreviate (or short enough to not need abbreviation), and convey it's audience as HTML authors or web developers |
| 13:44 | <Philip`> | annevk: That seems confusing because Authors are people who write books, and this isn't for them |
| 13:44 | <hsivonen> | this was also a problem with naming mozilla newsgroups |
| 13:45 | <hsivonen> | who "developers" are, that is |
| 13:45 | <Philip`> | Maybe "HTML 5 for Web Developers" |
| 13:45 | <zcorpan> | http://www.sitepoint.com/forums/showthread.php?t=594525 |
| 13:46 | <annevk> | Philip`, Web Authors then... |
| 13:46 | <Lachy> | does anyone have any feedback about the overview I just wrote? Does what it describes seem like a reasonable structure? |
| 13:48 | <Lachy> | karlcow, gsnedders, ^^ |
| 13:51 | <Philip`> | Lachy: I can't quite imagine someone who knows nothing about HTML reading through the Introduction and How To Read and Preface sections before reaching the introductory tutorial section that tells them how to write HTML, without them getting bored and giving up before then |
| 13:52 | <Philip`> | (Oh, and the Abstract and Status and TOC) |
| 13:53 | <Lachy> | The Abstract, Status and TOC are required. I'm considering droppin the How To Read section, but right now it's useful for trying to work out how the guide will be marked up. |
| 13:53 | <Lachy> | The Preface will probably merge with the introductory tutorial |
| 13:55 | <hsivonen> | all this charset stuff balloons into a scary amount of code |
| 13:55 | <hsivonen> | just imagine how simple this *could* have been |
| 13:56 | <karlcow> | Lachy: put the how to read section at the end of the document in an appendix and refers to it. aka someone might want to read it once but not necessary over and over again. Powah of hypertext |
| 13:56 | <Lachy> | hsivonen, do you mean if we had developed and standardised on UTF-8 and UTF-16, and never had CRLF from the very beginning? |
| 13:57 | <Philip`> | Lachy: Since they're required, maybe this is an unsuitable format for an introductory tutorial - for people who don't know anything about HTML and want an introductory tutorial, it seems better for them to Google for "html tutorial" and look at http://www.w3schools.com/html/html_intro.asp and immediately get an example and a "Try it yourself" link |
| 13:57 | <hsivonen> | Lachy: even if we'd had multiple encoding with exactly one simple in-file declaration mechanism |
| 13:57 | <hsivonen> | Lachy: but UTF-8-only would of course have been simpler |
| 13:57 | <karlcow> | hmmm maybe Philip` just found the appropriate title |
| 13:57 | <karlcow> | "HTML 5 Tutorial" |
| 13:58 | <hsivonen> | I mean: Gecko needs *16* different charset information source ranks! |
| 13:58 | <jgraham> | Lachy: I think for a non-normative authoring guide the scope section should vanish, the intended audience section should probably vanish, the preface doesn't seem very accurate |
| 13:58 | <Lachy> | karlcow, I don't really want to call the whole thing a Tutorial because that's more like what Dan C is producing |
| 13:58 | <hsivonen> | (15 currently, I'm adding one for HTML5-conformance) |
| 13:58 | <Philip`> | If it had been UTF-8-only, early text-mode web browsers would probably have not bothered implementing that correctly and would just dump the bytes to the terminal, and everyone would write in iso-8859-1 and the plan would fall apart |
| 13:58 | <Lachy> | jgraham, yeah, the preface is still a work in progress. But what specifically is inaccurate? |
| 13:59 | <jgraham> | Specifically I'm not clear that the second paragraph is accurate/useful |
| 14:00 | <jgraham> | The third paragraph is irrelevant |
| 14:00 | <jgraham> | (in that I don't think this document needs to justify its own existance so much) |
| 14:00 | <Lachy> | ah, it was somewhat relevant to the section it was originally in. Now with it being moved around so much, yeah, it has lost its relevance |
| 14:01 | <zcorpan> | Lachy: HTML5 Reference |
| 14:01 | karlcow | is always surprised how people are harsh in their comments. cf [09:05] <jgraham> The third paragraph is irrelevant |
| 14:02 | <jgraham> | karlcow: Fair enough, I was trying to be brief |
| 14:02 | <jgraham> | But then had to expand anyway so there was no point |
| 14:02 | <Lachy> | maybe I should just merge the scope, audience and overview into a single, more cohesive section |
| 14:02 | <karlcow> | brief can include love ;) |
| 14:02 | <takkaria> | karlcow: harsh or terse? |
| 14:02 | <karlcow> | takkaria: harsh |
| 14:03 | <Lachy> | karlcow, I like receiving harsh comments. It means people are actually thinking about what I'm doing and helping to ensure I don't produce crap |
| 14:03 | <jgraham> | Lachy: I think at this point it is more useful to focus on the content of the document than the ntroductory material. The introductory material can be written at the end and should just say what HTML is and something about what follows |
| 14:03 | <takkaria> | I'm certainly in the habit of being extremely terse when reviewing things, if it's harsh that's a side-effect |
| 14:03 | <karlcow> | Lachy: "I like receiving harsh comments" it has a name ;) the M part of SM |
| 14:04 | <jgraham> | karlcow: This isn't that sort of channel ;) |
| 14:04 | <Lachy> | what's SM? |
| 14:04 | <karlcow> | http://en.wikipedia.org/wiki/Sadomasochism |
| 14:05 | <jgraham> | karlkow: You were't refferrring to the scientific plotting application SuperMongo |
| 14:05 | <jgraham> | ?! |
| 14:05 | <karlcow> | A new world to explore for Lachy, I think we lost him for a while. To type also in google images ;) if you want more details |
| 14:05 | <Philip`> | Nor to Super Mario? |
| 14:08 | <Philip`> | It'd be interesting to see Google's stats on how many people choose to turn SafeSearch off |
| 14:08 | <Lachy> | I turn it off |
| 14:08 | <Lachy> | I don't like my porn searches being filtered ;-) |
| 14:08 | <jgraham> | Section 1.3.2.2.2 Void Elements, referencing "The XML well formedness requirement" doesn't make much sense since you haven't even explained that XHTML is an XML dialect or what XML is or anything (I think this is a reorganisation artefact) |
| 14:09 | <Lachy> | ok |
| 14:09 | <karlcow> | Lachy it is a good start for refactoring the document |
| 14:09 | <Philip`> | Trying to teach HTML and XHTML simultaneously sounds like it's just going to cause confusion |
| 14:09 | <jgraham> | In general it seems hard to deal with XHTML since most people who already understand the difference will think it obvious but most people who don't will skip the introduction |
| 14:10 | <annevk> | hmm, my attribute script fails on <embed> |
| 14:10 | <jgraham> | Although I always think writing things that teach anything well is close to impossible so I don't have the best opinion |
| 14:11 | <annevk> | and I suppose I should keep a list of elements as well besides a dictionary so you can get them in spec order... |
| 14:11 | <jgraham> | 1.3.2.2.1 Attributes - The concept of a boolean attribute and an expanded and minimised form has not been explained |
| 14:11 | <jgraham> | annevk: Ordered dictionary! |
| 14:12 | <annevk> | how do i get one of those? |
| 14:12 | <Philip`> | Use JavaScript |
| 14:12 | <jgraham> | annevk: http://www.voidspace.org.uk/python/odict.html |
| 14:12 | <jgraham> | Or write your own |
| 14:13 | <Philip`> | Seems far easier to use a list |
| 14:13 | annevk | finds http://www.python.org/dev/peps/pep-0372/ |
| 14:13 | annevk | agrees with Philip` |
| 14:14 | <jgraham> | Philip`: Well it depends really; if you have to maintain a list and a dict keeping them in sync is some effort |
| 14:14 | <annevk> | html5lib is actually cited in that pep |
| 14:14 | <annevk> | never knew we were so famous |
| 14:15 | <Philip`> | jgraham: If you're only appending, it's not a problem |
| 14:15 | <Philip`> | particularly if you don't care about asymptotic performance, so you can write "d[k] = v; if k not in l: l.append(k)" |
| 14:15 | <jgraham> | Philip`: If you're only appending it is pretty easy to write your own odict with that code in |
| 14:16 | <Philip`> | It's even easier to not write your own odict :-) |
| 14:16 | <karlcow> | hmmmm "dict -d html5 blockquote" could be handy |
| 14:18 | <jgraham> | Lachy: All the subsections 10 1.3.2.2 seem out of place. You are talking about concepts like attributes before you have even defined what they are. |
| 14:19 | <jgraham> | Which I guess is not a problem for most people assuming your internal audience statement is basically "people with preexisting knowledge of HTML" |
| 14:22 | karlcow | is trying to guess which document jgraham is talking about |
| 14:25 | <Lachy> | jgraham, which copy of the document are you reading? Are you reading a cached version? |
| 14:27 | <jgraham> | Lachy: Maybe. Paste the URL in case I am not looking at the right one |
| 14:27 | <Lachy> | http://dev.w3.org/html5/html-author/ |
| 14:29 | <jgraham> | OK, the subsections are of 2.1.2 |
| 14:29 | <jgraham> | (I had the older version before) |
| 14:30 | <karlcow> | jgraham: it is the how to read |
| 14:30 | <Lachy> | ah, ok. I've moved the How To Read section to the end, as karlcow suggested now, and added an issue stating that it may be dropped |
| 14:30 | <Lachy> | in my local copy. Not checked in yet |
| 14:32 | <Lachy> | hsivonen, from v.nu: "Error: End of file seen and there were open elements." - That would be much more useful if it told me which element wasn't closed |
| 14:32 | <hsivonen> | Lachy: ok |
| 14:32 | <hsivonen> | Lachy: status of this document says HTML 5 is not under /TR/ |
| 14:35 | <Lachy> | gsnedders, there's a weird bug with anolis where if a <section> element isn't properly closed, all the heading levels get messed up |
| 14:35 | <Lachy> | using the replaceHeadings plugin |
| 14:37 | <Lachy> | however, I must say that using <h1> for all headings in the source is proving extremely convenient for restructuring purposes |
| 14:38 | <Lachy> | I just wish there were a way to make TextMate recognise the section element, so it could be collapsed in source view like div can |
| 14:44 | <raspberry-lemon> | Lachy: i'm pretty sure you can edit textmate's html bundle |
| 14:45 | <Lachy> | raspberry-lemon, I probably can. I just need to figure out which file to edit |
| 14:45 | <raspberry-lemon> | you don't have to edit the file directly |
| 14:45 | <raspberry-lemon> | Bundles -> Bundle Editor -> Show Bundle Editor |
| 14:45 | <Lachy> | I renamed it to "HTML 5 Reference" with the subtitle "A Web Developer’s Guide to HTML 5" |
| 14:46 | <jgraham> | annevk: Not using html5lib is lame :) |
| 14:47 | <annevk> | if html5lib didn't delay processing by sixteen seconds |
| 14:48 | <Philip`> | Use lxml's HTML parser |
| 14:49 | <raspberry-lemon> | Lachy: inside the HTML bundle there's an item called HTML with a little L icon next to it |
| 14:49 | <jgraham> | annevk: It's not like you need to update the list very often |
| 14:50 | <raspberry-lemon> | if you replace the contents with http://gist.github.com/54566 it should let you collapse sections |
| 14:50 | <Philip`> | jgraham: The delay is a huge pain when updating the script during development, though |
| 14:50 | <jgraham> | Philip`: Fair enough |
| 14:52 | <Lachy> | raspberry-lemon, found it and fixed the folding support. I'll have to go through and add all the HTML5 elements later, once I figure out what the rest of the file does |
| 14:53 | <raspberry-lemon> | http://johnmuhl.com/notebook/textmate-html5-bundle looks like someone's on it already |
| 14:55 | <annevk> | jgraham, it was mostly due to what Philip` said |
| 14:58 | <Philip`> | A year ago, 9 pages (from 130K) had <!doctype html> |
| 14:59 | <Philip`> | A few days ago, 16 (from a different 130K) had <!doctype html> |
| 14:59 | <Philip`> | which doesn't seem like huge growth |
| 14:59 | <Lachy> | raspberry-lemon, nice. |
| 15:00 | <Philip`> | http://www.nimh.nih.gov/ is one |
| 15:00 | <Philip`> | from a year ago |
| 15:01 | <zcorpan> | Philip`: so xhtml is dying and html5 is rising? |
| 15:02 | <annevk> | Philip`, I like how that page also uses <head profile> |
| 15:02 | <Philip`> | http://www.haroldschogger.com/ also has a <!doctype html> if you look carefully |
| 15:03 | <raspberry-lemon> | <!--paste your source code between these comments --> |
| 15:04 | <raspberry-lemon> | there are still a loot of management type people who insist on xhtml no matter what |
| 15:04 | <Philip`> | zcorpan: Yes, based on the incontrovertible evidence of a few dozen pages |
| 15:04 | <Philip`> | But: |
| 15:04 | <Philip`> | Number of pages with doctypes containing the string "xhtml" a year ago: 23231 |
| 15:05 | <Philip`> | Number of pages with doctypes containing the string "xhtml" a few days ago: 32078 |
| 15:05 | <raspberry-lemon> | do you have the number of pages with no doctype at all? |
| 15:08 | <Philip`> | raspberry-lemon: Number of pages containing the substring "<!doctype" out of total number of pages processed: |
| 15:08 | <Philip`> | A year ago: 65085 / 124986 (52%) |
| 15:08 | <Philip`> | Some days ago: 73385 / 127208 (58%) |
| 15:08 | <wilhelm> | Interesting. |
| 15:08 | <Philip`> | though it's really dangerous to compare these numbers |
| 15:09 | <Philip`> | because the samples are not equally biased |
| 15:09 | <wilhelm> | Brian will do a recrawl with MAMA soon. Will be interesting to see what has changed. |
| 15:09 | <Philip`> | (They're both random samples from dmoz.org, but dmoz.org itself changes a lot, e.g. some sites add tens of thousands of their own pages which can distort the results) |
| 15:10 | <Philip`> | (so I should probably stop trying to compare the numbers, because the results will just be meaningless and misleading) |
| 15:11 | <Philip`> | ((That's "tens of thousands of their own pages" added to the 4.5 million in dmoz.org, so it's only hundreds in my samples)) |
| 15:13 | <Lachy> | for the very first example document, in the introductory tutorial, should I begin with the most basic <!DOCTYPE html><title>Foo</title><p>..., or should I include the <html>, <head> and <body>? |
| 15:13 | <wilhelm> | Yeah, cnn.com alone accounts for 5% of the pages on dmoz. |
| 15:14 | <Lachy> | hmm. Perhaps I should do the latter so that it helps readers understand the structure more easily |
| 15:14 | <Philip`> | wilhelm: It doesn't now, and didn't a year ago |
| 15:14 | <Philip`> | wilhelm: but it did at some point a bit earlier than a year ago |
| 15:14 | <zcorpan> | Lachy: don't omit tags, that's a confusing feature you should go into after all else (if at all) |
| 15:14 | <Philip`> | Lachy: Everybody writes <html> and <head> and <body>, so it's just unnecessarily confusing to try to tell them that it's unnecessary |
| 15:15 | <wilhelm> | Our data dump is a bit old. (c: |
| 15:15 | <zcorpan> | at least judging from comments on sitepoint forums |
| 15:15 | <annevk> | tag omission is prolly best learned from the spec itself :) |
| 15:16 | <Lachy> | zcorpan, the guide will cover tag omission |
| 15:16 | <zcorpan> | annevk: if you're serializing yes but not if you're writing markup - the rules for tag omission are not very understandable |
| 15:17 | <Lachy> | it will cover everything. The issue is just how and in what order things will be covered |
| 15:17 | <Philip`> | It particularly gets confusing if you tell people they can omit the tags, but if they want to use lang then they have to add some back in, and if they want a class then they have to too, etc |
| 15:17 | <Philip`> | and it only saves five lines of copied-and-pasted code, so it doesn't seem worthwhile |
| 15:18 | <zcorpan> | Philip`: having to not omit tags on which you want to use attributes seems not so confusing - it's more the rules when they can be omitted |
| 15:18 | <zcorpan> | (when having no attributes) |
| 15:19 | <annevk> | zcorpan, indeed, it will ensure that a small elite can still show of at parties with validating pages that omit various tags of which the elements are required |
| 15:19 | <Philip`> | zcorpan: It's the idea that you can omit tags and they implicitly exist even though you can't see them in your code, and that adding the tags into your code won't change the page at all (but will let you add attributes), that seems confusing |
| 15:20 | <Philip`> | zcorpan: since normally if you don't write something, it doesn't exist |
| 15:20 | <zcorpan> | Philip`: true |
| 15:20 | <jgraham> | <tbody> |
| 15:20 | <jgraham> | No one writes <tbody>, ever but it is always there |
| 15:20 | <jgraham> | Which is even more confusing |
| 15:20 | <Philip`> | The difference is that you can survive perfectly happily for many years without ever knowing a <tbody> is there |
| 15:20 | <zcorpan> | annevk: if the tag omission feature is only intended for a small elite (us?) i'd rather see the feature dropped |
| 15:21 | <Philip`> | where you'll need to know about <html> and <body> etc as soon as you add lang or class or style |
| 15:21 | <annevk> | mu |
| 15:21 | <Philip`> | s/where/whereas/ |
| 15:21 | <jgraham> | Philip`: Unless you ever write a script or certian CSS selectors that manipulate a table |
| 15:22 | <jgraham> | e.g. table#foo > td doesn't seem so implausible |
| 15:22 | <Philip`> | jgraham: Nobody uses child selectors |
| 15:22 | <Philip`> | And anyway that'd never match anything because you forgot the tr :-) |
| 15:23 | <jgraham> | Philip`: Presumably now IE supports child selectors, people will be more inclined to use them |
| 15:23 | <Philip`> | and if you're writing a script, you'll use the table.rows property |
| 15:24 | <zcorpan> | jgraham: why would you want to write table > td rather than table td ? |
| 15:24 | <jgraham> | Philip`: You would? Learning element-specific interfaces always seems like a lot of effort when you can always use a generic interface to do the same thing |
| 15:25 | <jgraham> | zcorpan: Realistically, because that's how you were thinking about it. Theoretically because it is faster |
| 15:25 | <jgraham> | Or because you have nested tables |
| 15:25 | <Philip`> | jgraham: Two thirds of pages with CSS don't even use descendant selectors |
| 15:25 | <annevk> | table > td is certainly faster, it doesn't match anything normally :) |
| 15:25 | <Philip`> | jgraham: so they're unlikely to flock to even more complex selectors |
| 15:25 | <jgraham> | annevk: :-p |
| 15:26 | <jgraham> | Philip`: Where did you get that data from? |
| 15:26 | <Philip`> | jgraham: http://triin.net/2006/06/12/CSS#figure-30 |
| 15:26 | <zcorpan> | jgraham: "table td" is less to type and looks nicer, but i take your point about nested tables |
| 15:27 | jgraham | wonders what he was wondering when he first typed "/me wonders" |
| 15:28 | <Philip`> | Just put a class on all your <td>s and then you don't have to worry about this selector mess at all |
| 15:28 | <jgraham> | Oh, I know, it was whether the CSS usage will have changed in the past 2 years or whether IE6 is still too influential |
| 15:28 | <Philip`> | (And I would assume very few people used nested tables that aren't CSSless layout tables) |
| 15:29 | <Philip`> | It'd be interesting to see how many of the non-trivial selectors are used for browser-targetting hacks rather than for anything sensible |
| 15:30 | <zcorpan> | i guess the most common child selector is html>body |
| 15:31 | <jgraham> | Anyway, the point is that a markup guide should mention tag inference because a) it is not really that hard to understand b) authors often unwittingly use it, specifically in the case of <tbody> |
| 15:32 | <Philip`> | I don't disagree that it should be mentioned :-) |
| 15:32 | <jgraham> | and c) if it is not mentioned it will confuse people who have never heard of <tbody> in HTML 4 and think it is a new concept in HTML 5 |
| 15:32 | <Philip`> | I just think it makes sense to promote (via the early text and the examples) a style which is closest to what people do today, e.g. always have html/head/body and never have tbody |
| 15:33 | <Philip`> | because that seems to work alright today |
| 15:33 | <zcorpan> | i think it's ok to be mentioned and even spell out the rules in a more understandable way than the spec (but possibly with less precision), but i wouldn't *start* with it |
| 15:34 | <jgraham> | zcorpan: That sounds sensible indeed. |
| 15:35 | <Philip`> | Yikes |
| 15:35 | <Lachy> | can anyone suggest a simple way to describe the meaning or purpose of a DOCTYPE, without going into details about standards mode? |
| 15:35 | <Philip`> | Lots of people use X-UA-Compatible |
| 15:35 | <Philip`> | 237 pages |
| 15:37 | <Philip`> | Lachy: "The <!DOCTYPE html> line tells the web browser that this is a modern web page, and stops it from emulating the bugs that are needed for compatibility with some old web pages" or something like that? |
| 15:37 | <Philip`> | (That's 237 pages with the X-UA-Compatible HTTP header) |
| 15:38 | <gsnedders> | Lachy: Do you have a minimal test-case? |
| 15:38 | <Lachy> | gsnedders, I will make one |
| 15:39 | <Philip`> | Common values: |
| 15:39 | <Philip`> | 120 IE=7 |
| 15:39 | <Philip`> | 114 IE=EmulateIE7 |
| 15:39 | <Philip`> | 2 IE=EmulateIE8 |
| 15:39 | <Philip`> | 1 X-UA-Compatible |
| 15:39 | <gsnedders> | Lachy: The algorithm used for headers is almost certainly correct per spec, and it is HTML 5 that is wrong. If the parsing is b0rked, that's somebody else's problem |
| 15:40 | <jgraham> | gsnedders: Oi |
| 15:40 | <gsnedders> | jgraham: :) |
| 15:41 | <Lachy> | yeah, it could be the parsing. I will certainly blame jgraham for the bug |
| 15:41 | <Philip`> | 644 pages use <meta blah x-ua-compatible>, though over half of those are IMDB and Myspace |
| 15:41 | <annevk> | :/ |
| 15:43 | <Philip`> | http://www.hindustantimes.com/ <meta http-equiv="X-UA-Compatible" content="IE=7;FF=3;OtherUA=4" /> - oh dear |
| 15:44 | <Philip`> | http://www.it-production.com/ <meta http-equiv="X-UA-Compatible" content="text/html; charset=iso-8859-1" /> |
| 15:45 | <Lachy> | gsnedders, maybe it's not a bug after all. I'm having difficulty reproducing it. I may have simply miscounted the number of section element start and end tags |
| 15:46 | <Lachy> | if it happens again, I'll investigate more thoroughly |
| 15:50 | <Lachy> | http://dev.w3.org/html5/html-author/#getting-started-with-html-5 |
| 15:50 | <Philip`> | 413 pages send X-Content-Type-Options: nosniff |
| 15:50 | <Philip`> | but only 59 if you exclude blogspot.com |
| 15:51 | <Lachy> | this is the first document that the tutorial will teach http://dev.w3.org/html5/html-author/examples/example01.html |
| 15:51 | <Philip`> | Lachy: The meta charset is scary |
| 15:51 | <Philip`> | Also, tabs are ugly |
| 15:52 | <Lachy> | I know, but I'm not going to omit the charset declaration from any document. Authors need to learn to always include it |
| 15:52 | <Lachy> | well, any HTML document. Not XHTML documents. |
| 15:52 | <Lachy> | not sure what I'll do about polyglot documents though |
| 15:56 | Philip` | wonders why he has a weird black pixel in his PDF document, and then realises it's because he accidentally used \dot instead of \bullet |
| 15:56 | <zcorpan> | "This line is used to indicate that the document is an HTML 5 document" hmm |
| 15:59 | <Philip`> | Lachy: That line (that zcorpan quoted) fails to give any justification to why authors should bother with typing that or why it's "good practice" |
| 15:59 | <Philip`> | and so a sensibly lazy author might decide to not bother with it |
| 15:59 | <Philip`> | I think it's important to say that if they don't have that line, their browser will be even weirder and buggier than it usually is |
| 16:00 | <Philip`> | so they're harming themselves if they don't use it |
| 16:00 | <jgraham> | Lachy: The sentence two before that is wrong when applied to XHTML (which is fine if you are using HTML to mean text/html but it doesn't look like yiou are) |
| 16:00 | <Philip`> | Oh, and if they don't have the doctype then they won't be able to use any new HTML5 features in IE8 |
| 16:01 | <Lachy> | jgraham, what makes you think I'm not using HTML to refer only to HTML? |
| 16:02 | <Lachy> | zcorpan, that's an incomplete sentence. I need to say something about validators |
| 16:02 | <Lachy> | or perhaps find some other way to say what the doctype is for |
| 16:02 | <zcorpan> | not sure you need to say anything about validators |
| 16:02 | <Lachy> | I really wanted to avoid the standards vs. quirks mode issue in this section |
| 16:03 | <zcorpan> | Lachy: since standards vs. quirks is the reason we have a doctype at all, it seems not mentioning it when explaining what it's for is going to be misleading |
| 16:03 | <jgraham> | Lachy: The fact that you use it to mean "HTML the abstract language" and "HTML the text/html serialisation of the abstract lanuage" |
| 16:03 | <Philip`> | You wouldn't need to explain the specific issues or the reason why it exists, but I think you need to state that it causes problems if you don't have it |
| 16:04 | <Philip`> | s/the reason/the historical reason/ |
| 16:12 | <Lachy> | "The purpose of the DOCTYPE is to ensure that web browsers interpret the document using standards mode, rather than the mode intended for handling legacy content." |
| 16:12 | <Lachy> | is that ok? |
| 16:13 | <gsnedders> | Lachy: "What's standards mode?" |
| 16:14 | <Lachy> | see, this is why I didn't want to go into that yet! |
| 16:16 | <Philip`> | It seems easier to phrase it as a negative, i.e. saying that it makes the browser not implement old bugs |
| 16:16 | gsnedders | agrees with Philip` |
| 16:16 | gsnedders | also agrees that it ought to be mentioned tehre |
| 16:16 | <gsnedders> | *there |
| 16:17 | <Lachy> | "For historical reasons, the purpose of the DOCTYPE is to ensure that web browsers do not interpret the document in a way intended for handling legacy content that exists on the web." |
| 16:18 | <jgraham> | The DOCTYPE is a holdover from the early days of the web. Using this doctype will ensure that web browsers do not try to replicate weird behaviour in older browsers that some content came to rely on |
| 16:18 | <Philip`> | Are you going to ignore that IE8 won't support new features at all, if you don't use the doctype? |
| 16:19 | <Philip`> | (so it's not just to prevent weird behaviour; it's to allow modern behaviour) |
| 16:19 | <gsnedders> | The DOCTYPE is required so that browsers do not treat the document as they treat legacy, non-standards compliant, content. |
| 16:19 | <Philip`> | gsnedders: That's just wrong |
| 16:19 | <wilhelm> | What's legacy content?:P |
| 16:19 | <Philip`> | gsnedders: because they'll treat perfectly standards-compliant HTML 3.2 content that way too |
| 16:19 | <gsnedders> | Philip`: How so? |
| 16:19 | <gsnedders> | Philip`: True. |
| 16:20 | <zcorpan> | wilhelm: deployed content |
| 16:20 | <gsnedders> | Philip`: And 4.01 Transitional |
| 16:20 | <gsnedders> | wilhelm: True. |
| 16:25 | <wilhelm> | zcorpan: _I_ know what it means, but I don't think that part of our tribal language equally well understood elsewhere. jgraham's wording is better, I think. |
| 16:25 | <wilhelm> | +is |
| 16:29 | <Lachy> | "The DOCTYPE is a remnant from the early days of the web. For historical reasons, it is needed to ensure that web browsers interpret the document correctly, rather than using a special compatibility mode designed to replicate the behaviour of older browsers, which is intended for handling legacy content." |
| 16:30 | <Lachy> | I'm still not sure what to replace "legacy content" with |
| 16:30 | <Lachy> | I used "legacy HTML content" |
| 16:31 | <Lachy> | I'm sure the meaning of legacy is well understood, and so that should be clear enough |
| 16:32 | svl | would drop the entire "which is intended" subclause. |
| 16:32 | <Lachy> | why? |
| 16:32 | <svl> | Keep your sentences as short as possible. |
| 16:32 | <Lachy> | ok |
| 16:32 | <svl> | and at first glance I find it confusing what "which" applies to. |
| 18:05 | <Philip`> | Trying to see where http://krijnhoetmer.nl/irc-logs/whatwg/20090129#l-588 came from: It looks like someone copied-and-pasted the "IE=8;FF=3;OtherUA=4" from http://www.alistapart.com/articles/beyonddoctype, then manually changed the 8 to a 7, leaving the rest unaltered, and then it spread around a handful of forum postings and web sites |
| 18:07 | <Philip`> | How can people be so unaware of what they're doing? Do they really think it's sane to have a version string that says any UA other than IE and Firefox should render as if it was version 4? |
| 18:08 | <Philip`> | Lachy: If you have invalid / bad practise examples in your authoring guide, please including some mouse event scripts that make it impossible for anyone to copy-and-paste from those examples |
| 18:08 | <Philip`> | s/including/include/ |
| 18:21 | gsnedders | wonders how much point there in applying to Opera — accommodation may well be horribly complex to arrange :\ |
| 18:23 | <wilhelm> | For an internship? |
| 18:23 | <gsnedders> | Yeah |
| 18:23 | <gsnedders> | (complex because I'm under the age of majority in most of Europe) |
| 18:26 | <wilhelm> | Opera has some apartments available for people staying for shorter periods of time. I'm not sure what the plans are for accomodation for summer interns, but it can't hurt to ask. (c: |
| 18:27 | <gsnedders> | wilhelm: There may well still be the issue of age, meh. |
| 18:35 | <takkaria> | wilhelm: thanks for mentioning the internship thing, I have an interview next friday :) |
| 19:16 | <wilhelm> | takkaria: Cool. Who's doing the interview? |
| 19:36 | <takkaria> | wilhelm: looks like Bibbi Svärd |
| 19:41 | <wilhelm> | Ah. At the Swedish office. |
| 19:43 | gsnedders | wonders what to write as a covering letter |
| 19:45 | <takkaria> | why you're interested in working there, highlighting relevant experience from your CV, explaining why you do or don't fit the requirements laid out in the description, roughly |
| 19:46 | <Philip`> | You should put some clipart on it too |
| 19:46 | gsnedders | blatantly sucks at applying :) |
| 19:48 | <gsnedders> | takkaria: Fun: I don't really have irrelevant experience on my CV :) |
| 19:49 | <takkaria> | well, you highlight the most relevant bits |
| 19:49 | <takkaria> | if it's all most relevant, choose some of it to highlight and highlight that |
| 19:51 | <Philip`> | You could make up some fake irrelevant experience, and then highlight the rest |
| 19:51 | <Philip`> | and because it's irrelevant nobody will ask you about it and so they'll never notice it's fake |
| 19:53 | <takkaria> | ideally, it should be at a small business whose boss was shot and whose premises were burnt down whilst thieves made off with the employment records for identity fraud purposes |
| 21:17 | <Hixie> | what's the new access control spec called again? |
| 21:17 | <Hixie> | CSRE? |
| 21:21 | <Philip`> | CORS? |
| 21:25 | <Hixie> | Philip`: thanks |
| 21:36 | <Dashiva> | So first there are lots of complaints that specifying error handling endorses errors |
| 21:37 | <Dashiva> | Even though the nonconforming attributes and stuff are hidden so Roy Fielding can't find them |
| 21:40 | <karlcow> | former: social effects with regards to browsers in face of authoring, latter: specifications on what has changed or not in a language. |
| 21:40 | <karlcow> | Conflating two different issues. tsss tsss ;) |
| 21:41 | <Dashiva> | If people can't find the nonconfirming stuff in the spec, they can't be confused to believe it's conforming |
| 21:43 | <karlcow> | Dashiva: the question is not here. |
| 21:53 | <Philip`> | Dashiva: He found enough of the nonconforming stuff (in the description of error handling for that attribute) to think it was a conforming part of the language, and there isn't anything that states it's non-conforming |
| 22:08 | <Lachy> | I like how, so far, that everyone who's whinging about the name attribute being omitted is silently ignoring the arguments that it was XHTML 1.1 that dropped it first. |
| 22:10 | <slightlyoff> | Lachy: most of the web silently ignores XHTML 1.1, so they're just following suit ;-) |
| 22:23 | <Lachy> | Hixie, re http://lists.w3.org/Archives/Public/public-html/2009Jan/0586.html ... |
| 22:24 | <Lachy> | with the audience defined as "... individuals wishing to establish the correctness of documents with respect to the requirements it describes.", including DOM APIs doesn't seem necessary |
| 22:25 | <Lachy> | to me, that audience section suggests that it's of more use to HTML conformance checkers, for which the DOM APIs have no relevance. |
| 22:25 | <Lachy> | unless they're going to try and check the conformance of a script too, which is impossible |
| 22:26 | <roc> | what the Web really needs is aesthetic conformance requirements |
| 22:30 | <slightlyoff> | roc: I'd like to browse the web through such a filter sometimes...oh, wait, that's what adblock is for |
| 22:32 | <Lachy> | roc, that's easy. Just add myspace.com/* to your adblock and youll block a significant portion of asthetically displeasing pages |
| 22:39 | <Dashiva> | Lachy: There's a firefox extension for myspace |
| 22:39 | <Lachy> | that does what? |
| 22:40 | <Dashiva> | https://addons.mozilla.org/en-US/firefox/addon/6067 |
| 22:41 | <Lachy> | LOL |
| 22:41 | <Lachy> | I gotta install that one |
| 22:41 | <Lachy> | oh, it doesn't work with FF3 |
| 22:42 | <roc> | oh noes |
| 22:43 | <Philip`> | If you block MySpace then you'll block a third of the RDFa namespaces I've seen on the web |
| 22:43 | <Philip`> | which would be a terrible thing |
| 22:43 | <Lachy> | cool, I can kill 2 birds with one stone |
| 23:05 | <Lachy> | for some reason, I'm not receiving any emails from Robert Burns that he's sending to the list. i'm only receiving Boris' replies. Is anyone else having the same problem? |
| 23:06 | <Philip`> | Lachy: Have you set up a filter to delete his mails? |
| 23:06 | <Lachy> | It looks like they're showing up in the archive, so I don't understand what's going on. They're not in my junk folder either, although I suppose that's where they belong anyway |
| 23:06 | <Lachy> | no, I don't delete any mails except spam, and he doesn't quite qualify as spam |
| 23:09 | <Lachy> | LOL :-D "you simply jump into the conversation with unrelated comments." - says the guy who jumps into a thread about dropping <a name=""> with ambiguous complaints about something else. |
| 23:09 | <Lachy> | http://lists.w3.org/Archives/Public/public-html/2009Jan/0592.html |
| 23:13 | <Hixie> | Lachy: you left off the first part, which is why the apis would be useful |
| 23:13 | <Hixie> | > This specification is intended for producers of documents |
| 23:13 | <Hixie> | > intended to conform to the requirements it describes |
| 23:13 | <Lachy> | I know. I think the first part needs to be dropped |
| 23:13 | <Lachy> | or revised |
| 23:14 | <Hixie> | well i'm trying to avoid arguing about what i think the audience statement should be, and just review the draft based on what it is |
| 23:14 | <Hixie> | what it _should_ be is imho mostly up to the editor |
| 23:15 | <Lachy> | ok. I'll argue about the audience statement with Mike then, since it seems easier than getting him to drop the Relax NG schemas and regexs from the draft |
| 23:33 | Hixie | tries to work out what to do about the script execution model around page navigation |
| 23:35 | <Hixie> | othermaciej: there's really no way i can get you to trade the massive complexity of multiple personality Window objects for the performance hit of cross-document script calls checking that the target code is still active? |
| 23:36 | <othermaciej> | Hixie: well - given that we have the split window solution already implemented, and that it was quite a bit of work to validate its security properties, I don't find the complexity reduction to be much incentive |
| 23:37 | <othermaciej> | Hixie: because we'll have to do a similar amount of work probably to make sure the new model works |
| 23:37 | <othermaciej> | so, given that it's also certain to be a significant performance hit, I'm not super enthusiastic about it |
| 23:37 | <Hixie> | othermaciej: Microsoft have teh opposite argument, so that one is pretty much a non-issue for me |
| 23:38 | <othermaciej> | Hixie: sure, I'm telling you why "massive complexity" does not count as a cost for the split Window solution |
| 23:38 | <Hixie> | (including the performance aspect, since i'm pretty sure multiple-window stuff has a perf hit elsewhere, e.g. page load) |
| 23:38 | <Hixie> | sure |
| 23:38 | <othermaciej> | also my understanding is that IE does something similar to split window, but I could be wrong |
| 23:38 | <othermaciej> | no, split window is not a hit to page load time |
| 23:38 | <Hixie> | not as far as i can tell |
| 23:38 | <othermaciej> | believe me we are very thorough about measuring these things |
| 23:38 | <Hixie> | they just turn off scripts |
| 23:38 | <othermaciej> | in fact it enabled us to implement some additional optimizations |
| 23:39 | <Hixie> | so is there any way i can get you to describe exactly what you do, in terms of the EcmaScript spec? |
| 23:39 | <othermaciej> | IE has orders of magnitude slower JS than anyone else, so I think their input on the importance of the perf hit is not credible |
| 23:39 | <othermaciej> | I can try to describe it |
| 23:40 | <Hixie> | (re perf - that's not a politically tenable position for me to hold, unfortunately) |
| 23:40 | <othermaciej> | for the lifetime of any given frame, including a top-level frame, there is an "outer" Window object |
| 23:40 | <othermaciej> | for any given Document, there is an "inner" Window object |
| 23:41 | <Hixie> | do either of these map to the global object? |
| 23:41 | <othermaciej> | there is a one-to-one correspondence between browsing contexts and outer Window, and between Documents and inner window |
| 23:41 | <othermaciej> | the inner window acts as the global object |
| 23:41 | <othermaciej> | for purposes of the scope chain and in general providing the global scope |
| 23:41 | <othermaciej> | getting back to my narrative... |
| 23:41 | <othermaciej> | the outer window delegates all property and method access to the inner window |
| 23:41 | Hixie | lets you explain it before asking further questions :-) |
| 23:42 | <othermaciej> | on navigation, the outer window's associated inner window is replaced with the one for the new current document |
| 23:42 | <othermaciej> | in the scope chain, you have the inner window |
| 23:42 | <othermaciej> | when you access "this" in global scope, or access the global "window" property, or in any other way reify a reference to the global object, you get the outer window |
| 23:42 | <othermaciej> | thus, any mechanism you use to get an actual object reference gives you a persistent one |
| 23:43 | <othermaciej> | but function scopes see their original defining global object in their scope chain |
| 23:43 | <othermaciej> | the inner window is the "true" global object, and the outer window is a persistent handle to whatever is the current global object for a given browsing context |
| 23:44 | <othermaciej> | the way this prevents exploits is that a function defined in a frame when the frame had a different document, but somehow persisted, sees the old global variables, not the new global variables |
| 23:44 | <othermaciej> | unless it stored a reference to the outer window, but in that case, a security check applies |
| 23:44 | <othermaciej> | the kind of exploit this is trying to prevent is: |
| 23:44 | <othermaciej> | evil.com has a top-level document with a subframe, also on evil.com |
| 23:45 | <othermaciej> | the inner frame defines a function, and passes it to the outer frame |
| 23:45 | <othermaciej> | the attacker navigates the subframe to victim.com |
| 23:45 | <othermaciej> | in a naiive implementation of persistent global objects, the saved function has access to the global variables and document of victim.com |
| 23:46 | <othermaciej> | but split window prevents that, because the saved function sees the old global variables |
| 23:46 | <othermaciej> | I will also note, this kind of design makes it much easier to implement a back-forward cache |
| 23:46 | <othermaciej> | it greatly simplified our page cache implementation |
| 23:46 | <Hixie> | (the spec prevents it by refusing to run the function) |
| 23:46 | <Hixie> | so as far as i can tell, what you describe violates the EcmaScript spec |
| 23:46 | <othermaciej> | right - refusing to run the function is not a practical option, because it would require a security check at every JS-to-JS call boundary |
| 23:47 | <Hixie> | specifically section 10.2.1, which says the scope chain and |this| are the same object. |
| 23:47 | <Hixie> | are you in the ecmascript meeting by any chance? |
| 23:47 | <othermaciej> | the one happening today? no |
| 23:47 | <othermaciej> | but I can raise this issue with the ECMAScript group |
| 23:47 | <Hixie> | k |
| 23:47 | <Hixie> | that would be good |
| 23:47 | <othermaciej> | I'm not sure if the 'this' behavior is essential for compatibility |
| 23:47 | <Hixie> | since apparently i'm going to make HTML5 violate the spec |
| 23:47 | <othermaciej> | I know the fact that 'window' returns the outer reference is |
| 23:48 | <Hixie> | which window is the one with the Math object on it? outer or inner? |
| 23:48 | <Hixie> | and do any calls to outer just forward to the current inner? |
| 23:49 | <othermaciej> | inner is the one that really has a Math property - the outer forwards to the inner, so as far as anyone can observe, it also has a Math property pointing to the same object |
| 23:49 | <Hixie> | does the outer object's prototype change dynamically? or does it just appear to have teh inner's prototype? |
| 23:49 | <othermaciej> | now you found something that I actually need to look up :-) |
| 23:49 | <Hixie> | heh |
| 23:49 | <othermaciej> | or better yet ask weinig |
| 23:49 | <othermaciej> | weinig: ayt? |
| 23:49 | <weinig> | yes |
| 23:50 | <Hixie> | rubys: i'm in the cafe btw |
| 23:50 | <othermaciej> | weinig: how does the prototype of the outer window work, with respect to split window? |
| 23:50 | <weinig> | othermaciej: it should not be visible to the user |
| 23:50 | <othermaciej> | weinig: does it change on navigation or is it just totally separate from the inner prototype? |
| 23:50 | <othermaciej> | weinig: ok |
| 23:50 | <weinig> | othermaciej: it should always reflect the prototype of the current inner window |
| 23:51 | <othermaciej> | so if you get the __proto__ property on the outer window, you get the current inner window's prototype? |
| 23:51 | <Hixie> | weinig: so a = window.__proto__; navigate(); a !== window.__proto__ ? |
| 23:52 | <Hixie> | i guess i can spec this |
| 23:52 | <Hixie> | i've only rewritten this part of the spec about a dozen times so far |
| 23:52 | <Hixie> | :-) |
| 23:52 | <weinig> | Hixie: that should be the case |
| 23:52 | <Hixie> | k |
| 23:54 | <Hixie> | this is going to make the object returned by window look mighty hoopy in idl |
| 23:55 | <Hixie> | ok i'll do this later. time to find the js guys. |
| 23:55 | <Hixie> | bbl |