| 00:10 | <ap> | Hixie: is splitting text nodes during parsing something the HTML spec would be concerned about? WebKit stopped doing that while implementing HTML5, but looks like it was quite bad for performance |
| 00:10 | <ap> | so we may have to reintroduce that |
| 00:12 | <Hixie> | why is it bad for perf? |
| 00:13 | <othermaciej> | extra allocation and copying, I would presume |
| 00:13 | <othermaciej> | though I'm not sure what benchmark ap is looking at that convinces him it's an issue |
| 00:13 | <Hixie> | why would one long string need more allocation and copying than more shorter strings? |
| 00:14 | <ap> | Hixie: search and replace algorithms that create new nodes hit this (think about an algorithm that finds all e-mails with a regexp, and replaces them with <a> links) |
| 00:15 | <ap> | Hixie: it's not about WebKit own performance, but about performance of scripts and other clients |
| 00:16 | <Hixie> | i don't understand why the number of DOM nodes needs to have any correlation to the number of allocations in the background, nor why editing fewer larger strings needs to be slower than more editing smaller strings. |
| 00:16 | <ap> | Hixie: yeah, I need to explain in more detail |
| 00:16 | <Hixie> | just implement the DOM string as an interface on top of a string system that uses whatever is optimal for the platform |
| 00:17 | <Hixie> | e.g. if someone tries to splice something into the middle of a string, you can just have the DOM node be stored as two strings and an edit point |
| 00:17 | <Hixie> | no need to move the original string at all |
| 00:17 | <Hixie> | etc |
| 00:18 | <ap> | Hixie: say, you're processing a string line aaa<ian⊙hc>bbb, and need to replace it with aaa<a href="mailto:ian⊙hc">ian⊙hc</a>bbb |
| 00:19 | <ap> | Hixie: you have to split the text, and copy "bbb" into a new node |
| 00:19 | <ap> | Hixie: the larger nodes are, the more time it takes |
| 00:19 | <Hixie> | only if your implementation of text nodes is naive |
| 00:20 | <Hixie> | if you split the dom text nodes so that you have adjacent nodes in the dom, all you're going to do is break implementations that don't expect it |
| 00:20 | <ap> | Hixie: I can add to that that the strings are round tripped to a client via an API |
| 00:20 | <Hixie> | s/implementations/pages/ |
| 00:21 | <ap> | Hixie: given that both Gecko and WebKit used to split, those pages were already broken |
| 00:21 | <Hixie> | so e.g. if the dom nodes are [aaa<ap@web] and [kit.org>bbb], pages will likely miss it entirely |
| 00:21 | <ap> | Hixie: you are talking about a pretty serious amount of sophistication for a CharacterData implementation here |
| 00:22 | <Hixie> | sure |
| 00:22 | <Hixie> | i'd rather browsers be sophisticated that rely on web page authors to be sophisticated :-) |
| 00:22 | <Hixie> | or as others would say, the "priority of constituencies" puts authors ahead of browsers |
| 00:23 | <ap> | Hixie: my priority here is to prevent real applications from freezing due to this change |
| 00:24 | <ap> | Hixie: I'm only working on a fix, and wanted to touch bas first, but it's pretty unlikely that we'll keep apps freezing until the desired level of sophistication is reached |
| 00:25 | <Hixie> | thanks for the heads-up |
| 00:25 | <othermaciej> | ap: is there a web app that has an N^2 problem with growing text nodes? |
| 00:26 | <othermaciej> | giant run of plaintext I would guess? |
| 00:26 | <ap> | othermaciej: <rdar://problem/9013049> |
| 00:26 | <ap> | othermaciej: in that case, it's also about memory use |
| 00:28 | <othermaciej> | ap: I shall comment internally, given the nature of that bug |
| 01:31 | <TabAtkins_> | Hixie: I started using <xmp> today in Lists. It makes my life easier. |
| 01:33 | <aho> | what's xmp? :l |
| 01:34 | <TabAtkins_> | Like <pre>, but you don't need to escape anything inside of it. |
| 01:34 | <aho> | :o |
| 01:34 | <TabAtkins_> | So <xmp>To bold something, type <b>.</xmp> actually says what you'd expect. |
| 01:35 | <aho> | can't find it in the html5 specs... or well... anywhere |
| 01:35 | <TabAtkins_> | It's in the "obsolete elements" section right now. |
| 01:35 | <aho> | only found some old blog post which says it's deprecated |
| 01:36 | <aho> | hm |
| 01:36 | <TabAtkins_> | Webkit, at least, actually supports <xmp> properly. It's quite helpful when writing HTML examples |
| 01:36 | <aho> | on my blog i'm using some input filter to get this kind of effect |
| 01:37 | <aho> | i always thought that this was a tad strange |
| 01:37 | <TabAtkins_> | For yourself, or for comments? |
| 01:37 | <aho> | myself |
| 01:37 | <TabAtkins_> | (This does *not* protect you against code injection from comments.) |
| 01:37 | <TabAtkins_> | Ok, yeah. |
| 01:37 | <TabAtkins_> | I write my blog in markdown, so the code blocks in markdown automatically know to escape their contents when serializing to HTML. |
| 01:38 | <aho> | well, i kinda like it and i always wanted something like that for my other technical documentation |
| 01:38 | <aho> | right now i always search/replace < and >, but that's somewhat annoying |
| 01:38 | <aho> | needless to say that it also makes the markup kinda ugly |
| 01:38 | <TabAtkins_> | You don't need to replace >, but you *do* need to replace &. |
| 01:39 | <TabAtkins_> | (> is safe everywhere except in unquoted attribute values) |
| 01:39 | <aho> | i replace <, &, and > (for symmetry) :> |
| 01:40 | <aho> | is xmp something from html 3.x? |
| 01:40 | <aho> | ah... 2.0 it seems |
| 01:41 | <Philip`> | I don't think there's any HTML spec in which it wasn't already deprecated |
| 01:41 | <aho> | also <plaintext> and <listing>... weird :) |
| 01:41 | <oojacoboo> | does anyone know if the pseudo class :focus will allow styling of other elements based on that event or if it's only binded to the styling of that particular element? |
| 01:42 | <aho> | there is still no way to specifiy the programming language of a <code> block, right? |
| 01:42 | <TabAtkins_> | oojacoboo: I don't understand what you mean. |
| 01:42 | <TabAtkins_> | aho: No way in HTML, yeah. |
| 01:43 | <oojacoboo> | TabAtkins_: this is my selector that doesn't work... form.schweet li.help-tip input:focus + a.tipper |
| 01:43 | <TabAtkins_> | (Various javascript syntax-highlighting scripts recommend ways to mark it up.) |
| 01:43 | <oojacoboo> | here is one that does... form.schweet li.help-tip:hover a.tipper |
| 01:44 | <TabAtkins_> | Okay. There's nothing wrong with the former. As long as the input is focused, and the rest of the structure is right, then it will work. |
| 01:44 | <oojacoboo> | TabAtkins_: it doesn't :/ |
| 01:44 | <TabAtkins_> | oojacoboo: I'd have to see your code. There's nothing wrong with the selector, so you're doing something else wrong. |
| 01:44 | <oojacoboo> | it's the most awkward thing I've seen |
| 01:45 | <oojacoboo> | I wish I could get you the code, it's a massive application |
| 01:45 | <aho> | ye, most of them use classes for that, but that's not quite right... i mean... there is zero semantic weight behind it. some micro format bs would work, i guess. but i'd prefer some regular attribute for that. i mean, <code> *is* for source code in *some* language |
| 01:45 | <TabAtkins_> | aho: Use data-src-lang or something. |
| 01:46 | <aho> | right now, i'd use data-lang, yes ;) |
| 01:47 | <aho> | Although there is no formal way to indicate the language of computer code being marked up, authors who wish to mark code elements with the language used, e.g. so that syntax highlighting scripts can use the right rules, may do so by adding a class prefixed with "language-" to the element. |
| 01:47 | <aho> | meep :> |
| 01:47 | <oojacoboo> | TabAtkins_: am I wrong in assuming that the cursor doesn't have to be over the input for :focus to be triggered? |
| 01:47 | <oojacoboo> | I thought the cursor sitting in an input kept the :focus event triggered |
| 01:47 | <TabAtkins_> | oojacoboo: Focus, for an input, is when the caret is in the input. |
| 01:48 | <TabAtkins_> | It has nothing to do with the mouse cursor. |
| 01:48 | <oojacoboo> | strange... |
| 01:48 | <TabAtkins_> | Why is it strange? That's what it means to "focus" an input. |
| 01:48 | <aho> | there can be only one element with focus... if an element got focus it will receive keyboard input |
| 01:48 | <TabAtkins_> | Yes. |
| 01:49 | <oojacoboo> | the behavior I am seeing is very strange, that event handling is as expected |
| 01:49 | <aho> | typically <tab> can be used to focus the next element and <shift>+<tab> jumps backwards |
| 01:49 | <oojacoboo> | aho: right |
| 01:50 | <aho> | clicking on some element also gives it focus |
| 01:50 | <oojacoboo> | yea, I actually know how it works, just not experiencing it |
| 01:50 | <TabAtkins_> | oojacoboo: Can you get :focus to work on its own, like "input:focus { outline: thick solid red; }" ? |
| 01:50 | <oojacoboo> | TabAtkins_: yes |
| 01:51 | <oojacoboo> | that much is handled correctly |
| 01:51 | <oojacoboo> | background-color, color, etc |
| 01:52 | <TabAtkins_> | oojacoboo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/865 |
| 01:52 | <aho> | input:focus+label works in ff3.6... i just tried that |
| 01:53 | <aho> | (completely useless, but yes, that works) :> |
| 01:53 | <oojacoboo> | trying to see if something else is the culprit here |
| 02:01 | <oojacoboo> | TabAtkins_: no clue, it seems to be working fine in the testcases where I try to replicate, clearly something else is going on... thanks for your help, if I find something I'll report back |
| 02:01 | <TabAtkins_> | No problem. |
| 02:01 | <TabAtkins_> | Unrelated: A virus so big it gets viruses: http://arstechnica.com/science/news/2011/03/a-virus-so-large-it-gets-viruses.ars?utm_source=twitterfeed&utm_medium=twitter&utm_campaign=rss |
| 02:11 | <aho> | would be nice if there would be something like focus, which bubbles up like hover :> |
| 02:12 | <aho> | input:focus+label <- e.g. that kind of thing would be useful if i could write it the other way around |
| 02:12 | <TabAtkins_> | label:has-sibling(input:focus), someday... |
| 02:12 | <aho> | but with some focus bubbling thingy i could do that via the wrapper |
| 02:13 | <aho> | .whatever:focus-bubble-voodoo>label :> |
| 02:15 | <aho> | putting the label after the text fields would work of course, but that makes positioning a nightmare |
| 02:15 | <aho> | and of course you'd end up with pure nonsense if you look at it without css |
| 02:20 | <aho> | input:focus^label (adjacent previous sibling, lol) |
| 02:20 | <aho> | well, would be nice to have |
| 02:20 | <aho> | it's also kinda funny how css ran out of special chars :> |
| 02:23 | <oojacoboo> | aho that'd be awesome |
| 02:24 | <zewt> | input☺focus |
| 02:24 | <aho> | input(ノ ゜Д゜)ノ 彡 ┻━┻focus |
| 02:24 | <aho> | rage table flip combinator |
| 02:25 | <zewt> | input工工工ｴｴｴｴｴｴｪｪｪｪｪｪ(ﾟДﾟ)ｪｪｪｪｪｪｴｴｴｴｴｴ工工工focus |
| 02:26 | <aho> | :) |
| 02:28 | <aho> | well, there aren't too many "regular special characters" left and even most of those which are currently used don't make any sense whatsoever |
| 02:29 | <zewt> | can use longer tokens where it's not ambiguous |
| 02:29 | <aho> | yea, :whatever(...) will always work, but that's kinda awful :> |
| 02:30 | <aho> | input:focus:previous-adjacent-sibling(label){... uh hum...} |
| 02:30 | <zewt> | a::b->c@@d |
| 02:31 | <zewt> | as long as it doesn't devolve into the gnu regex absurdities like [:digit:] or whatever, heh |
| 02:31 | <aho> | [href$=".pdf"] |
| 02:31 | <aho> | :> |
| 02:33 | <aho> | but to be honest, i only use a very small subset of css selectors/combinators for the things i currently build (with some architecture n stuff) |
| 02:37 | <oojacoboo> | aho: honestly, you rarely need the special ones |
| 02:37 | <oojacoboo> | I've built a very advanced application that uses a lot of css, and very rarely need special selectors |
| 02:39 | <aho> | i do virtually everything with the child combinator |
| 02:39 | <oojacoboo> | what do you mean? |
| 02:39 | <aho> | the descendant one is only used for recursion :> |
| 02:39 | <oojacoboo> | .this < .that |
| 02:39 | <aho> | > |
| 02:39 | <oojacoboo> | gotcha |
| 02:40 | <aho> | everything is a sub tree which can be plugged in any leaf of any other sub tree |
| 02:40 | <aho> | works great so far |
| 02:41 | <oojacoboo> | you can't always go up the DOM though |
| 02:41 | <oojacoboo> | esp when you need pseudo classes |
| 02:42 | <aho> | you cant go up or backwards with css |
| 02:42 | <aho> | only down and forwards |
| 02:42 | <oojacoboo> | yea, but what I mean is, you can't always target a parent |
| 02:42 | <oojacoboo> | or use that parent rather, in the selection |
| 02:42 | <aho> | (well, strictly speaking it's the other way around since selectors are evaluated from right to left) :> |
| 02:42 | <aho> | of course i can |
| 02:43 | <oojacoboo> | how can I do this then... |
| 02:43 | <aho> | the markup is created that way from the very beginning |
| 02:43 | <aho> | first structure, then markup/css |
| 02:43 | <oojacoboo> | li:focus a.tipper {} where I have... <li><input /><a></a></li> |
| 02:43 | <aho> | and not arbitrary markup which i then try to beat into submission via css :> |
| 02:44 | <oojacoboo> | aho: of course, that's why I am saying I almost never have an issue |
| 02:44 | <oojacoboo> | so long as you have control over the DOM, you are almost always ok |
| 02:45 | <oojacoboo> | in that example I want to do something like... li(li a) < input:focus {} |
| 02:46 | <oojacoboo> | obv that doesnt' make sense, but pass the event on the input to style down from the <li> |
| 02:46 | <aho> | li isn't focusable by default |
| 02:47 | <aho> | <li tabindex="0" ...> makes it focusable |
| 02:47 | <aho> | but that's all kinds of ugly :> |
| 02:47 | <oojacoboo> | really?? |
| 02:48 | <oojacoboo> | is that legit |
| 02:48 | <zewt> | iirc not consistently supported |
| 02:49 | <aho> | well, focus doesnt bubble up anyways |
| 02:49 | <oojacoboo> | right |
| 02:49 | <aho> | so, if some input inside that li got focus... then this one got the focus any nothing else gets it :> |
| 02:49 | <aho> | *and |
| 02:50 | <aho> | that's why i said it would be nice to have something like focus which bubbles up like hover :> |
| 02:50 | <oojacoboo> | mmm yea, just saying it'd be nice to be able to have it bubble or, or hack that somehow |
| 02:50 | <oojacoboo> | li < input:focus {} |
| 02:51 | <oojacoboo> | you'd get something sorta like that, but how could you apply that to children of the li |
| 02:51 | <zewt> | people have complained about focus events not bubbling since forever, heh |
| 02:52 | <oojacoboo> | obv not enough people ;) |
| 02:54 | <zewt> | oh it's mouseover/mouseout bubbling that i'm thinking of |
| 08:14 | <annevk> | http://www.isolani.co.uk/blog/standards/MicrosoftsAntiIe6Rhetoric |
| 08:51 | <annevk> | I pulled bug before the comment: http://html5.org/tools/web-apps-tracker |
| 08:51 | <annevk> | Renamed "R" to "SVN" and "B" to "Bug" |
| 08:51 | <annevk> | better? |
| 12:41 | <hsivonen> | Hixie: FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=638842 |
| 14:01 | <foolip_> | gsnedders, you there? |
| 14:18 | <gsnedders> | foolip_: Vaguely. |
| 14:18 | <foolip_> | gsnedders, I was going to ask how the spec section ids are generated, but then I found secid.py |
| 14:34 | <foolip_> | gsnedders, although, now it looks like secid.py isn't actually used in anolis2, did I find the wrong code? |
| 14:35 | <foolip_> | maybe the code is just invoked in some more roundabout way than actually importing secid and calling secid.Process... |
| 14:51 | <kukman> | There is some bug in Selections in Opera |
| 14:51 | <kukman> | http://jsfiddle.net/pEqeu/2/ |
| 14:51 | <kukman> | and, if you click mouse anywhere else, space between numbers will be still selected |
| 17:23 | <annevk> | Could also name the SVN column HTML |
| 17:23 | <annevk> | currently at HTML5944 |
| 21:37 | <Yuhong> | Making HTML XML-valid then omit the xmlns because of a hate for namespaces? Huh? |
| 21:37 | <Yuhong> | http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid-html5 |
| 21:38 | <zewt> | generally i tend not to take anyone seriously who uses the world "fail" in all caps |
| 21:50 | <aho> | personally, i kinda like STOP EVERYTHING error handling :> |
| 21:51 | <aho> | i mean... gee... we are able to produce all kinds of well-formed formats. there is nothing magical about html which makes it impossible |
| 21:52 | <Dashiva> | aho: Why do you hate your users? |
| 21:53 | <aho> | a broken image wont work |
| 21:53 | <aho> | a broken archive wont work |
| 21:53 | <aho> | a broken css file wont work |
| 21:53 | <aho> | a broken js file wont work |
| 21:53 | <Dashiva> | Sure they do |
| 21:54 | <aho> | about as well as broken xml, yes |
| 21:54 | <Dashiva> | You use broken css files and images every day |
| 21:55 | <Dashiva> | Same with JS files, for that matter |
| 21:55 | <aho> | we're talking about non recoverable errors |
| 21:55 | <zewt> | "not strictly correct" != "broken"; if it works it's, by definition, not broken. heh |
| 21:55 | <aho> | not things like ASI |
| 21:56 | <aho> | "the image ... contains errors and cannot be displayed" :> |
| 21:56 | <Dashiva> | zewt: Except that's how XML defines broken |
| 21:56 | <aho> | well, try writing some junk into the header of a jpg file |
| 21:56 | <aho> | see how that works |
| 21:56 | <aho> | :P |
| 21:57 | <zewt> | we're speaking english, not XML :P |
| 21:57 | <zewt> | aho: JPEGs aren't human-writable, so they can be a lot less forgiving |
| 21:58 | <aho> | how about obj (wavefront) then? |
| 21:58 | <aho> | technically it's human readable, too |
| 21:58 | <zewt> | don't know it |
| 21:58 | <aho> | it's a text based model format |
| 21:59 | <aho> | needless to say that things will go horribly wrong if you put some random junk data into one of those obj files :> |
| 21:59 | <zewt> | even readers for binary formats generally have to be forgiving of certain errors, when buggy software puts weird files in the wild; eg. reading AVIs is a serious pain |
| 22:00 | <aho> | well, that's what html5 is kinda doing... it tries to specify this error handling |
| 22:00 | <aho> | beforehand the result was just random |
| 22:00 | <aho> | that's not any good, really :) |
| 22:00 | <aho> | so yea, it should be either very strict and if it isn't the result should be predictable |
| 22:01 | <aho> | the latter is of course a lot more complicated |
| 23:33 | <aho> | there really should be a global vendor prefix registry which is maintained by browser vendors |
| 23:33 | <aho> | the current state is somewhat troublesome |
| 23:34 | <paul_irish> | how so |
| 23:34 | <paul_irish> | like when things go unprefixed.. and what existing prefixed props are supported by each? |
| 23:34 | <aho> | there are hundreds of prefixes and figuring out which one is still needed is pretty time consuming |
| 23:34 | <aho> | yes |
| 23:35 | <paul_irish> | hundreds of prefixes? i thought there were only 4 practical ones.. and then like ~14 that are in some spec somewhere. |
| 23:35 | <aho> | like -moz-opacity was required for firefox <0.9 and it's completely ignored since 3.5 |
| 23:36 | <Peter-> | I got history info on http://peter.sh/experiments/vendor-prefixed-css-property-overview/ which I plan to do things with |
| 23:36 | <paul_irish> | mozilla and google are (and will be) documenting that on the MDC |
| 23:36 | <Peter-> | the primary problem is that gecko and webkit can be automated, whereas Opera and Microsoft cannot |
| 23:36 | <Peter-> | (I did e-mail them) |
| 23:37 | <aho> | http://code.google.com/p/cssmin/source/browse/tags/version-2.0/cssmin.php |
| 23:37 | <aho> | line 386 and up |
| 23:37 | <gsnedders> | Peter-: Automated in what way? |
| 23:38 | <Peter-> | Both Gecko as WebKit maintain a single file in which all properties are available |
| 23:38 | <aho> | where is that file? |
| 23:38 | <aho> | havent seen it on mdc |
| 23:38 | <Peter-> | I fetch them every three hours, parse the files into individual properties and update my db |
| 23:38 | <Peter-> | it also feeds the rss feed |
| 23:39 | <Peter-> | http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/style/nsCSSPropList.h |
| 23:39 | <Peter-> | http://trac.webkit.org/export/0/trunk/Source/WebCore/css/CSSPropertyNames.in |
| 23:39 | <gsnedders> | Right, so it's just a bi-product of them being open-source. |
| 23:39 | <aho> | ahm... ok... pulling it out of the source directly |
| 23:39 | <aho> | hoped there was some json file or even xml or whatever |
| 23:39 | <Peter-> | Opera doesn't maintain a single (or conveniently accessible) list. Microsoft has a few pages on MSDN which list all, but usually with a 3/4 month delay |
| 23:40 | <Peter-> | I do have a json |
| 23:40 | <aho> | linky? :) |
| 23:41 | <Peter-> | http://peter.sh/data/vendor-prefixed-css.php |
| 23:41 | <paul_irish> | hero! |
| 23:41 | <aho> | :D |
| 23:43 | <Peter-> | I have code (and data) for such lists on all properties (including non-prefixed ones) per browser version somewhere too, but I *really* need to finish that sometime soon |
| 23:44 | <aho> | would be cool if that would end up in some official place (i.e. some place which can be actually found by anyone) |
| 23:44 | <paul_irish> | what were you searching for to attempt to find it? |
| 23:45 | <paul_irish> | 'List CSS Style Properties' ? |
| 23:46 | <gsnedders> | Peter-: FWIW, publishing a complete list of properties supported for any Presto version should be trivial |
| 23:48 | <aho> | paul_irish, me? i look most of them up on mdc and i crosschecked that IE stuff with msdn. that's about it. |
| 23:48 | <paul_irish> | k |
| 23:48 | <aho> | didn't know where else to look |
| 23:49 | <aho> | gsnedders, would be awesome :) |
| 23:49 | <Peter-> | gsnedders, I requested it late last year but never got a reply. The presto docs are complete, but the properties are listed all over the place |
| 23:49 | <Peter-> | that makes it hard to automate |
| 23:50 | <gsnedders> | Peter-: I can quite trivially send you a .txt file with one property per line |
| 23:50 | <aho> | soo... only microsoft is missing then eh? :) |
| 23:50 | <Peter-> | gsnedders, that'd be great |
| 23:50 | <gsnedders> | Peter-: Do you want multiple versions or just latest? |
| 23:51 | <Peter-> | gsnedders, just the latest will do. My e-mail address is peter⊙lc |
| 23:51 | <Peter-> | gsnedders, thank you! |
| 23:53 | <aho> | Peter-, got some twitter account? (would like to be up to date on this heh) :> |
| 23:54 | <Peter-> | aho, I'm @beverloo. I don't really have an ETA, but it surely is high on my list :) |
| 23:54 | <aho> | twitter stalkers++ |
| 23:54 | <smaug____> | why does <progress> have .form? |
| 23:55 | <aho> | ah yea, twiter already told me several times to stalk you, too :) |
| 23:56 | <Peter-> | Cool :-). I'm off to bed for now, night |
| 23:56 | <aho> | nn |
| 23:57 | <smaug____> | ah, hmm, nm |
| 23:58 | <smaug____> | er, no, I don't still get it |