| 00:12 | <AryehGregor> | Hixie, why drop the syntax sugar for walking the keys of a Storage object? |
| 00:12 | <AryehGregor> | Syntax sugar is nice. |
| 03:05 | <Hixie> | AryehGregor: because it only saved 4 characters anyway, it was inconsistent in setting and getting, only 1 browser out of 5 implemented it, and what the other browsers did is not compatible (they couldn't implement it without potentially breaking content that assumed their behaviour). |
| 10:29 | <Figaroo> | Hi all |
| 10:31 | <benjoffe> | it seems adding an link with the 'tel:' attribute will annoy more users than it will help, as desktop browser that can't handle it still render the link clickable |
| 10:33 | <sholmes> | that is, when a new line is created and overflows the element's height, the text should have an ellipsis |
| 10:33 | <sholmes> | You know what I'm saying? |
| 10:34 | <sholmes> | wait my last message didn't go through. |
| 10:34 | <sholmes> | Is it possible to use text-overflow for text that overflows the height? |
| 13:16 | <annevk> | Opera has an extension for that ellipsis problem... |
| 17:18 | <webr3> | true? -> "In HTML5, rel and rev are no-longer paired, and the rel attribute no longer describes the direction of a relationship. Microformats which use rev will need to use rel instead." |
| 17:19 | <webr3> | rel no longer has directionality, as in "currentdoc rel href" as a typed directed link is no longer the case, and rel is some generic relation between the two uris, such that "A rel B" and "B rel A" both hold as true |
| 17:34 | <annevk> | webr3, there's no rev |
| 18:18 | <webr3> | annevk, yup i know there's no rev, but what about directionality, and how do you actually do a reverse link? |
| 18:19 | <webr3> | well, no rev in the draft html 5 / living standard spec, well there is it's mentioned in a few places, but shouldn't be used, but when it is, it's catered for, in some places |
| 18:19 | <Philip`> | rel is directional, and you can do a reverse link by using a rel keyword with the opposing meaning |
| 18:19 | <webr3> | okay, so directionality is based on the property used in the rel ya? |
| 18:20 | <Philip`> | Yes, that defines the directionality of the meaning |
| 18:21 | <Philip`> | e.g. rel="next" says the linked page is next after the current one, and rel="prev" says it's previous to the current one |
| 18:22 | <Philip`> | so instead of rev="next" you can use rel="prev", etc |
| 18:22 | <webr3> | A next B infers B prev A |
| 18:22 | <Philip`> | which is typically less confusing (people use rev wrongly about as often as they use it correctly) |
| 18:24 | <webr3> | and some are bidirectional i assume? alternate for example? |
| 18:25 | <webr3> | what's the inverse of author? |
| 18:27 | <webben> | webr3: The inverse of author is to add a rel="author" back from the authored page to the author page. |
| 18:36 | <AryehGregor> | Hmm. I should have tested extend() with diacritics. |
| 18:39 | <AryehGregor> | Thankfully Firefox is sane and treats the offsets as corresponding to characters (or maybe code units?) and not grapheme clusters. |
| 18:39 | <AryehGregor> | But modify() still works on grapheme clusters. |
| 18:39 | <AryehGregor> | At least with "character". |
| 18:40 | <AryehGregor> | Seems like it's all code units. |
| 18:45 | <AryehGregor> | Okay, so in WebKit all Range boundary points have to fall on grapheme cluster boundaries, it looks like . . . that seems bad. |
| 18:45 | AryehGregor | goes with Firefox and the current spec on that point |
| 18:58 | <Philip`> | Does "grapheme cluster boundaries" mean "code unit boundaries after NFC normalisation"? |
| 18:58 | <Hixie> | no |
| 19:01 | <Ms2ger> | So, what should happen to cx.createImageData("1", "2")? |
| 19:01 | <AryehGregor> | Philip`, no, because a character and its diacritics count as one grapheme cluster even if there's no composed form. |
| 19:01 | <AryehGregor> | In fact, UAX29 defines everything in terms of NFD. |
| 19:07 | <Philip`> | Ms2ger: It should teach API designers the foolishness of typed-based overloading in a dynamically-typed language |
| 19:07 | <Ms2ger> | I was actually hoping you'd write a test ;) |
| 19:07 | <Philip`> | and then it should do whatever the convoluted algorithms in WebIDL say it should do, unless WebIDL is wrong |
| 19:08 | <Philip`> | (Maybe WebIDL just looks at the number of arguments and ignores the types?) |
| 19:08 | <Philip`> | (Hmm, no, it can't do that) |
| 19:08 | Philip` | shrugs |
| 19:15 | <webr3> | webben, you you're saying that on an html page if I do "A author B" then it infers that "B is author of A" and if I do "A author B" on another page (the authors page) then it infers that "A is author of B" |
| 19:22 | AryehGregor | just rewrote everything in DOM Range like "If the position of new start relative to the context object's end is after" to something like "If new start is after the context object's end" |
| 19:23 | <AryehGregor> | I love the convention of making normal words mean magical stuff by making them hyperlinks. |
| 19:25 | <Philip`> | Sounds like you're one of those fancy modern programmers who likes using subroutines |
| 19:26 | Philip` | doesn't think they'll catch on - much better to be explicit and write everything out in full each time |
| 19:31 | <Ms2ger> | Who uses functions anyway? |
| 19:45 | <zcorpan> | hsivonen: the validator could maybe give a clearer message if you put body stuff in head |
| 19:45 | <zcorpan> | http://validator.nu/?doc=http%3A%2F%2Fdevelopers.whatwg.org%2F |
| 19:46 | <hsivonen> | zcorpan: yeah. grammars strike again |
| 19:46 | <zcorpan> | hsivonen: but you could do something in the html parser, no? |
| 19:47 | <hsivonen> | zcorpan: do you mean error 6 and keeping track of whether body was implied? |
| 19:47 | <zcorpan> | hsivonen: e.g. when you see </head> or <body> but body was implied, emit a warning saying which token implied body and say it should be moved into the body or so |
| 19:47 | <zcorpan> | yeah |
| 19:48 | <hsivonen> | ok. that's doable |
| 19:51 | <zcorpan> | should i file a bug? |
| 19:57 | <hsivonen> | zcorpan: that would be nice |
| 19:59 | <webben> | webr3: No. |
| 20:00 | <webben> | webr3: I'm saying there isn't a registered inversion of author |
| 20:01 | <webben> | webr3: Nobody's registered authoredby or anything like that. |
| 20:04 | <AryehGregor> | Hixie, okay, so do you really want me to try figuring out what things like "sentenceboundary" mean? I assume that's got to be left mostly platform-specific anyway. |
| 20:05 | <AryehGregor> | I'm not sure what parts we'd want to spec here. Ideally not too vague . . . |
| 20:07 | <AryehGregor> | But I can't see how to realistically be specific. |
| 20:08 | <AryehGregor> | I'm thinking stuff like "paragraphboundary: The beginning or end of a paragraph, where a paragraph might correspond to the text selected when the user triple-clicks (on platforms using that convention)." I.e., enough to give you an idea, not much more. |
| 20:10 | <webr3> | webben, looks like you're seeing author as it's inversion, { <page> author <person> } means <person> is the author of <page>, <link rel="author" href="<person>" /> - I'm looking for the inverse of that, which would be "author of" in english, not "authored by" - "authored by" is the meaning of the "author" rel |
| 20:11 | <webben> | webr3: Sorry, yeah I mean pageauthoredby or work or something. |
| 20:11 | <webben> | webr3: Anyway nobody's registered what you want, so if you want it, define and register it I guess. |
| 20:12 | <webr3> | that process is going to have to be repeated for every rel, which is a shame |
| 20:14 | webben | shrugs. |
| 20:17 | <Ms2ger> | webr3, that's assuming we need all reverse relationships. The fact that rev has never taken off suggests we don't |
| 20:33 | <Hixie> | AryehGregor: if it's an API, i don't see how ti can be anything but strictly defined |
| 20:33 | <Hixie> | AryehGregor: otherwise people will use the API and get different results |
| 20:34 | <AryehGregor> | Hixie, because selection.modify("extend", "right", "line") is meant to mimic the effect of Shift+Down, for instance. In particular, its effect depends on things like where lines are broken and what font is used. |
| 20:34 | <AryehGregor> | There's no way we can spec that unless CSS is specced pixel-perfect. |
| 20:35 | <AryehGregor> | Logically, this is a visual API, not a DOM one. |
| 20:35 | <AryehGregor> | (the modify() part is, I mean) |
| 20:35 | <AryehGregor> | (extend() can be defined in terms of DOM alone, although WebKit seemingly doesn't implement it that way) |
| 20:36 | <AryehGregor> | Also, we want modify("extend", "right", "character") to depend on the definition of a grapheme cluster, which isn't really defined anywhere and should defer to how the platform behaves when the user does Shift+Right anyway. |
| 20:37 | <AryehGregor> | Similarly modify("extend", "right", "word") == Ctrl+Shift+Right, etc. |
| 20:43 | <benschwarz> | zcorpan: thanks for the bug report |
| 20:45 | <zcorpan> | benschwarz: thanks for fixing it :) |
| 20:46 | <zcorpan> | oh you meant the newest bug |
| 20:47 | <benschwarz> | one at a time :) |
| 20:47 | <benschwarz> | I have no idea why the spec splitter is doing that right now |
| 20:47 | <benschwarz> | I actually had a brief look over the weekend |
| 20:47 | <benschwarz> | no idea |
| 20:49 | <zcorpan> | Philip`: ^ |
| 20:50 | <Philip`> | Doing what? |
| 20:51 | <benschwarz> | Philip`: we have a <header class="head"> in the developer spec. The spec splitter seems to place it inside <head> |
| 20:55 | <benschwarz> | really it should be <header role="banner">, but thats another story :) |
| 20:56 | <zcorpan> | role=banner is implied by <header> no? |
| 20:56 | <zcorpan> | or maybe that was dropped |
| 20:56 | <benschwarz> | zcorpan: if its at the top level… I think |
| 20:57 | <zcorpan> | seems spec says header has no implied role but banner is allowed |
| 20:57 | <zcorpan> | ...to be specified |
| 20:59 | <Philip`> | benschwarz: What's the input file? |
| 20:59 | <Philip`> | Also, what version of the spec-splitter? |
| 21:00 | <Philip`> | Also, what command-line arguments? |
| 21:00 | <benschwarz> | ttp://www.whatwg.org/specs/web-apps/current-work/dev-index |
| 21:00 | <benschwarz> | only --html5lib-serialiser |
| 21:01 | <Hixie> | AryehGregor: that's why this is hard |
| 21:01 | <Hixie> | AryehGregor: doesn't mean we don't define it :-) |
| 21:01 | <volkmar> | someone remembers why all attribute float changed to attribute double? |
| 21:01 | <Hixie> | AryehGregor: there's nothing wrong with referencing CSS in these definitions |
| 21:02 | <benschwarz> | Philip`: as for version… its HEAD about a week about |
| 21:02 | <benschwarz> | ago |
| 21:02 | <benschwarz> | Hixie: good morning :) |
| 21:02 | <Hixie> | hey ben |
| 21:03 | <benschwarz> | Hixie: we have rudimentary offline support and search… |
| 21:03 | <Hixie> | cool |
| 21:03 | <AryehGregor> | Hixie, we can't get script-testable interop anyway. Things like line breaking aren't specced. CSS itself doesn't define word or character boundaries for the purposes of things like :first-letter. |
| 21:03 | <AryehGregor> | Besides, the whole point of the API is to match what the user does when they hit arrow keys and so on, which is inherently platform- and browser-dependent. |
| 21:04 | <benschwarz> | I need to roll to the office. First day back for this client |
| 21:04 | <AryehGregor> | Using uniform definitions that don't match what browsers do for normal user interaction defeats the point of the API, and I doubt browsers would implement it. |
| 21:04 | <erlehmann> | the whatwg logo. is there a canonical svg version? |
| 21:04 | <benschwarz> | Philip`: it looks like http://www.whatwg.org/specs/web-apps/current-work/dev-index is missing a <HEAD> to begin with… |
| 21:05 | AryehGregor | solicits Ms2ger's opinion |
| 21:05 | <Ms2ger> | Present, sir! |
| 21:05 | <Hixie> | AryehGregor: at least "line", "paragraph", "line boundary", and "document boundary" are completely definable |
| 21:05 | <Hixie> | AryehGregor: looks like a lot of the others aren't interoperably implemented anyway and maybe shouldn't be defined |
| 21:05 | <AryehGregor> | Hixie, are they? "Line" depends on line-breaking, which isn't interoperable. |
| 21:06 | <Philip`> | benschwarz: The head start tag is optional |
| 21:06 | <Ms2ger> | Not interoperable, but still definable |
| 21:06 | <Hixie> | AryehGregor: just define it in whatever terms CSS uses so that as we fix CSS it'll become interoperable |
| 21:06 | <Philip`> | benschwarz: I'm wondering whether your version of lxml is accidentally parsing the header as inside the head, or something |
| 21:06 | <erlehmann> | found it http://lists.w3.org/Archives/Public/www-archive/2009Apr/att-0042/logo.svg |
| 21:06 | <Hixie> | AryehGregor: e.g. use the same wording for letter boundaries as ::first-letter, or whatnot |
| 21:07 | <benschwarz> | Philip`: in the real world, everyone uses a <head> |
| 21:07 | <Hixie> | AryehGregor: same wording for word boundaries as text-transform:capitalise |
| 21:07 | <AryehGregor> | Hixie, so how do I work CSS into it? Does CSS have any notion of mapping between line boxes and the parts of the DOM they represent? |
| 21:07 | <AryehGregor> | IIRC, CSS just doesn't define those. :) |
| 21:07 | <benschwarz> | so despite the fact that its optional. most people expect them |
| 21:07 | <AryehGregor> | It makes more sense to informatively reference UAX#29. |
| 21:07 | <Hixie> | AryehGregor: start reading and learning the css2.1 spec :-) |
| 21:07 | <AryehGregor> | I have . . . it's horrifyingly vague. |
| 21:08 | <benschwarz> | maybe all I have to do is plead with Hixie to add a <head> :) |
| 21:08 | <Philip`> | benschwarz: Hmm, did you modify the splitter so the serialiser outputs explicit <head> etc? |
| 21:08 | <Philip`> | (It doesn't seem to do that by default) |
| 21:08 | <Hixie> | benschwarz: dev-index is generated by anolis |
| 21:09 | <AryehGregor> | Look at this, it just doesn't define line boundaries at all: http://www.w3.org/TR/CSS21/selector.html#first-line-pseudo |
| 21:09 | <AryehGregor> | There's nothing to reference. |
| 21:09 | <Hixie> | benschwarz: but <head> is optional, the element is still there even if the tag isn't |
| 21:09 | <Hixie> | benschwarz: so so long as you're using a conforming parser you should be fine |
| 21:09 | <Hixie> | AryehGregor: for line boxes you want chapters 8, 9 and 10 iirc, not ::first-line |
| 21:10 | <AryehGregor> | I've read those before. |
| 21:10 | <AryehGregor> | I don't see how they're useful. |
| 21:10 | <Philip`> | benschwarz: Where does the <link rel="stylesheet" href="/css/master.css"> come from? |
| 21:12 | <AryehGregor> | I think I should ask the people implementing this what sort of description they'd like to see. |
| 21:12 | <Hixie> | AryehGregor: they define how the display boxes (line boxes, inline boxes, line-wrapping, etc) are done |
| 21:12 | <benschwarz> | Philip`: I add it in postprocessing |
| 21:12 | <Philip`> | Added how? |
| 21:13 | <Philip`> | I would guess your postprocessing tools are probably using non-HTML5-conforming parsers |
| 21:13 | <Philip`> | and are failing to correctly imply a <body> start tag when they see the <header> start tag |
| 21:13 | <Philip`> | since the splitter seems to be working correctly, as far as I can tell |
| 21:14 | <benschwarz> | hmm |
| 21:14 | <benschwarz> | let me verify |
| 21:14 | <Philip`> | (lxml looks okay to me) |
| 21:14 | <benschwarz> | Philip`: lxml would've been okay for many versions by now |
| 21:15 | <AryehGregor> | I'll send an RFC to whatwg. |
| 21:15 | <Ms2ger> | Not the IETF? |
| 21:16 | <benschwarz> | you must be right Philip` |
| 21:16 | <Philip`> | The splitter outputs <html ...><title>...</title><!-- ... --><meta ...> <script src="link-fixup.js"></script> <header class="head"> ... |
| 21:16 | <Philip`> | which is perfectly valid and means the header element is inside the body element |
| 21:16 | <benschwarz> | The parser I'm using is nokogiri, which is uses on libxml2… |
| 21:17 | <benschwarz> | due to the amount of postprocessing I'm doing, a <head> would be useful anyway… |
| 21:18 | <Philip`> | Add omit_optional_tags=False in the splitter's HTMLSerializer line if you want nothing omitted |
| 21:21 | <benschwarz> | Thanks Philip` I will try that |
| 21:21 | <benschwarz> | now… I need to leave for the office |
| 21:21 | <benschwarz> | or else I'll be late :) |
| 21:23 | <benschwarz> | Philip`: hmm. header still in the head |
| 21:23 | <benschwarz> | I'll keep trying to diagnose it later… |
| 21:23 | <benschwarz> | thanks for the heads up |
| 23:30 | <AryehGregor> | Is any version of .innerText specced anywhere? |
| 23:32 | <gsnedders> | No |
| 23:33 | <AryehGregor> | Yay. |
| 23:33 | <AryehGregor> | I assume it's unreasonably complicated. |
| 23:34 | <gsnedders> | It's more complex than it seems at face-value, IIRC |
| 23:34 | <gsnedders> | Note WebKit has a high-cost for changing their innerText behaviour as a lot of their tests depend upon the exact serialization. |
| 23:35 | <AryehGregor> | Nice. |
| 23:35 | <othermaciej> | we could easily make the tests use something than innerText |
| 23:35 | <othermaciej> | it's not encoded in every text or anything |
| 23:36 | <AryehGregor> | So what's an example of a difference between innerText and textContent? |
| 23:36 | <othermaciej> | but it would suck to carry around multiple conversion to plaintext algorithms |
| 23:36 | <gsnedders> | othermaciej: Converting existing tests' expectations would be expensive, though, at least provided you actually check the change |
| 23:37 | <gsnedders> | AryehGregor: head element, scripts |
| 23:37 | <AryehGregor> | Ah. |
| 23:37 | <othermaciej> | yeah, but there's no need to convert expectations |
| 23:37 | <othermaciej> | we would convert the test harness |
| 23:37 | <gsnedders> | othermaciej: Ah, to match the current innerText behaviour? |
| 23:39 | <AryehGregor> | innerText also seems to do newline collapsing of some kind. |
| 23:40 | <AryehGregor> | Actually, whitespace collapsing generally. |
| 23:40 | AryehGregor | gets to work writing a spec |
| 23:51 | <gsnedders> | AryehGregor: Also note it should be affected by the computed style |
| 23:51 | <gsnedders> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/809 for example |
| 23:51 | <AryehGregor> | Yeah, I've figured that part out. |
| 23:52 | <AryehGregor> | display: none is suppressed, display: block adds newlines, etc. |
| 23:52 | <gsnedders> | AryehGregor: the float and position properties change semantics too |
| 23:52 | <AryehGregor> | Oh, dear. |
| 23:53 | <AryehGregor> | Wait, how so in this case? I get "foo magic bar" as I'd expect. |
| 23:54 | <gsnedders> | Try removing the float. |
| 23:54 | <gsnedders> | It becomes "foo\nmagic\nbar" v. "foo magic bar" with the float |
| 23:54 | <AryehGregor> | Ah, so it makes it behave like an inline. |
| 23:54 | <AryehGregor> | Or something. |
| 23:54 | <AryehGregor> | Does Firefox not implement this? |
| 23:55 | <gsnedders> | innerText isn't supported by Gecko |
| 23:55 | <AryehGregor> | Doesn't that imply it's not needed for compat, so we can retire it in favor of textContent? Why do we want to spec it? |
| 23:58 | <AryehGregor> | Also, on a somewhat related note, does anyone know if Ranges' stringifier does anything weird? It looks like it behaves more or less like textContent, just copying the DOM. |
| 23:58 | <AryehGregor> | Which would be nice if true. |
| 23:58 | <Philip`> | if(vjo.dsf.client.Browser.bFirefox){oL.textContent=_d;}else{oL.innerText=_d;} |
| 23:59 | <Philip`> | (on search.blogs.ebay.com) |
