| 07:53 | <annevk> | in WebKit, document.body.setAttribute() creates undefined="undefined" |
| 07:53 | <annevk> | that's still not fixed? |
| 07:56 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=315805 |
| 07:57 | <AryehGregor> | annevk, that's a problem with their WebIDL bindings, right? Don't all methods do that, pretty much? |
| 07:57 | <AryehGregor> | They don't throw on too few arguments being passed. |
| 07:59 | <annevk> | AryehGregor: f8dy fixed their IDL bindings, but I guess he never fixed the broken methods |
| 08:01 | <AryehGregor> | If he fixed the IDL bindings, how could that not throw? It would have to have the params declared as optional or something. |
| 08:01 | <annevk> | right |
| 08:01 | <annevk> | make for DOM takes almost 10 seconds? |
| 08:01 | <annevk> | what is so difficult? |
| 08:38 | <annevk> | the problem with the namespace algorithms in DOM seems to be that they do not account for multiple attributes |
| 08:38 | <annevk> | I guess nobody looks at them and that's why we haven't noticed until now? |
| 08:38 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#locate-a-namespace-prefix |
| 08:38 | <annevk> | you could have multiple attributes xmlns:test="x" xmlns:test2="x" etc. |
| 08:39 | <annevk> | which local name you return is not defined |
| 08:39 | <annevk> | then in http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#locate-a-namespace you have the same problem |
| 08:39 | <annevk> | actually, in that case you can have only one such attribute I think |
| 08:40 | <annevk> | other question |
| 08:41 | <annevk> | should http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-element-setattributens have all those restrictions given that setAttribute() can be used to circumvent them? |
| 08:55 | <Von_Davidicus> | Hello... |
| 08:55 | <Ms2ger> | Or maybe add the restrictions to setAttribute? Or would that break facebook? |
| 08:55 | <Ms2ger> | Also, <!doctype html> on http://www.w3.org/TR/2012/WD-dom-20120405/ , I guess I'll have to believe that they mean it now |
| 08:55 | <annevk> | Ms2ger: I just removed those |
| 08:55 | <Ms2ger> | Oh |
| 08:55 | <annevk> | Ms2ger: nobody implements them |
| 08:55 | <Ms2ger> | Mm |
| 08:58 | <annevk> | Von_Davidicus: use <section> combined with <h1> |
| 08:59 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=742549 o_O |
| 09:01 | <Von_Davidicus> | I thought <h1> was the top-level header. |
| 09:02 | <annevk> | that changed with the introduction of <section> |
| 09:03 | <Von_Davidicus> | That seems a bit screwy with semantics, but then, I'm easily confuzzled. :) |
| 09:04 | <annevk> | HTML is not entirely logical either, so that's fine :) |
| 09:06 | <Von_Davidicus> | Oh, don't I know it. HTML seems really simple--right up until you try to -explain- it. |
| 09:09 | <Von_Davidicus> | So does <section> essentially reset the header numbering? For example, I could have the headers in the main page, and then have, say, <section class="code_example"> and start the example heading over at <h1>? |
| 09:12 | <annevk> | yeah more or less |
| 09:12 | <annevk> | Von_Davidicus: reading http://www.whatwg.org/C#outline might help |
| 09:16 | <Von_Davidicus> | <!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HyperText Markup Language//EN"> |
| 09:16 | <Von_Davidicus> | |
| 09:16 | <Von_Davidicus> | ", will it still validate? |
| 09:16 | <Von_Davidicus> | And sorry for the linebrakes. |
| 09:16 | <annevk> | don't think so |
| 09:17 | <annevk> | try http://validator.nu/ to be sure |
| 09:17 | Von_Davidicus | was kidding. :) |
| 09:17 | <annevk> | I think we do allow some old doctypes |
| 09:18 | <annevk> | but better to stick to <!doctype html> |
| 09:19 | <annevk> | Ms2ger: about features strings, can you ping eseidel somehow about which he wants to support? |
| 09:20 | <annevk> | Ms2ger: he was the one you were talking with this about that right? |
| 09:20 | <annevk> | Ms2ger: and maybe ask Gecko too? |
| 09:20 | <annevk> | Ms2ger: source code or otherwise :p |
| 09:22 | <annevk> | ooh |
| 09:22 | <annevk> | Mozilla just moved fullscreen to Element |
| 09:22 | <annevk> | hmm |
| 09:23 | <Von_Davidicus> | Another question, more serious this time: how will XHTML5 handle character entity references? I tried it and got Firefox's Yellow Screen of Death. |
| 09:25 | <annevk> | Von_Davidicus: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-xhtml-syntax has some details |
| 09:25 | <annevk> | Von_Davidicus: best to just use HTML |
| 09:26 | <annevk> | Von_Davidicus: or stay away from named entities |
| 09:28 | <Von_Davidicus> | Okay. |
| 09:34 | <annevk> | http://trac.webkit.org/changeset/111028/trunk/Source/WebCore/dom/Document.idl |
| 09:34 | <annevk> | hmm |
| 09:34 | <annevk> | both Mozilla and W3C version |
| 09:34 | <annevk> | never mind that Fullscreen is not done at the W3C |
| 09:34 | <annevk> | at least not that I know of |
| 09:59 | <annevk> | haha |
| 09:59 | <annevk> | http://www.alistapart.com/authors/�/tantekcelik |
| 10:03 | Von_Davidicus | ponders whether or not to turn one of his pages from HTML 4.01 to HTML5 |
| 10:09 | <Philip`> | Von_Davidicus: You shouldn't bother, unless it'll give any practical benefits to your page's users |
| 10:09 | <Philip`> | Better to spend the effort on more meaningful changes :-) |
| 10:11 | <Von_Davidicus> | Well, the page hasn't needed a change in a while. |
| 10:16 | <Ms2ger> | annevk, I dunno if I talked to anybody at webkit |
| 10:18 | <annevk> | Ms2ger: but I do |
| 10:18 | <annevk> | Ms2ger: https://bugs.webkit.org/show_bug.cgi?id=76214#c5 |
| 10:19 | <Ms2ger> | Ah, indeed |
| 10:20 | <Von_Davidicus> | Hmmm... if the "checked" attribute isn't allowed, how DO I preselect a checkbox? |
| 10:22 | <Von_Davidicus> | or, for that matter, "readonly"? |
| 10:22 | <annevk> | it is allowed |
| 10:22 | <Philip`> | Von_Davidicus: Who says it's not allowed? |
| 10:23 | <Von_Davidicus> | Well, the W3C validator I just checked my page on. |
| 10:24 | <Philip`> | It reports no error for me for e.g. "<!DOCTYPE html><title></title><input type=checkbox checked>" |
| 10:25 | <Philip`> | (though the spec doesn't allow readonly on checkboxes) |
| 10:26 | <Von_Davidicus> | The tags I'm having trouble with are: <input name="Rods_Count" class="rod_count readonly" type="hidden" readonly="readonly" value="0"> and <input name="Rods_Choose" class="rod_check" type="hidden" checked="checked">. |
| 10:26 | <volkmar> | annevk: where is window.fullscreen spec'd? |
| 10:26 | <Philip`> | Von_Davidicus: checked is meaningless (hence not allowed) for type=hidden |
| 10:27 | <Philip`> | Same for readonly for type=hidden |
| 10:27 | Von_Davidicus | will thus have to redo some of his PHP. |
| 10:27 | <Philip`> | (http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#hidden-state-(type=hidden) gives the details) |
| 10:28 | <Von_Davidicus_> | And, possible, some of my JavaScript. |
| 10:28 | <Ms2ger> | annevk, http://wiki.whatwg.org/wiki/DOM_features should have all those that Gecko supports now |
| 10:29 | <Philip`> | Von_Davidicus: Why are you specifying those attributes here, when they don't make sense for hidden inputs? |
| 10:30 | <volkmar> | annevk: forget the question... I realize it's not part of a spec... |
| 10:31 | <annevk> | volkmar: that attribute does not exist; see http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html |
| 10:31 | <volkmar> | annevk: https://developer.mozilla.org/en/DOM/window.fullScreen |
| 10:31 | <Von_Davidicus_> | Because I need them there for my JavaScript to work. |
| 10:32 | <annevk> | volkmar: do we need that attribute for something? |
| 10:32 | <annevk> | volkmar: it seems you can already accomplish that using matchMedia and for element fullscreen you can check document.fullscreenElement |
| 10:32 | <annevk> | it's also incorrectly cased |
| 10:33 | <volkmar> | annevk: sadly, seems like document.fullscreenEnabled is cased mozFullScreenEnabled in Gecko |
| 10:33 | <annevk> | hopefully that's fixed when they unprefix |
| 10:33 | <Ms2ger> | Do we have a bug to unprefix? |
| 10:34 | <annevk> | Firefox is standardizing on "fullscreen" after all and so is the rest of the world |
| 10:34 | <annevk> | (in UI language) |
| 10:37 | <Von_Davidicus_> | Basically, my code assumed that every table row would have those elements in it--and the inputs were hidden if they weren't actually needed. |
| 10:41 | <annevk> | Ms2ger: haven't seen anything |
| 10:42 | <annevk> | I'm having a hard time to not prematurely merge big5 and big5-hkscs |
| 10:42 | <Ms2ger> | I'll file |
| 10:43 | <annevk> | cool |
| 10:43 | <annevk> | hopefully Gecko can create some sanity in the all the Fullscreen code out there |
| 10:44 | <annevk> | I haven't seen much community feedback btw; I guess it works good enough... |
| 10:44 | <Ms2ger> | Facebook uses it for photos, I hear |
| 10:44 | <annevk> | youtube, vimeo, etc. use it |
| 10:45 | <annevk> | but all with lots of code paths because of the prefixes, prefixed events, etc. |
| 10:45 | <annevk> | it's quite the mess |
| 10:50 | <volkmar> | annevk: fullscreen specs say "HTML defines under what conditions the fullscreen enabled flag is set" |
| 10:50 | <volkmar> | but I don't see anything in the html specs |
| 10:51 | <annevk> | yeah HTML needs to be updated |
| 10:52 | <annevk> | not sure if I filed a bug on that already |
| 10:52 | <annevk> | but basically, I think the latest was that <iframe allowfullscreen> sets that flag |
| 10:52 | <annevk> | for the document it contains |
| 10:52 | <annevk> | and it's set automatically for the top-level browsing context's document |
| 10:52 | <volkmar> | annevk: so, to know if a document is fullscreen, you have to do fullscreenElement != null, right? |
| 10:53 | <annevk> | to know if an element is fullscreen you do that |
| 10:53 | <annevk> | if you want to know if the user used some kind of UI you would use media queries |
| 10:54 | <volkmar> | so, a dev can't know if the page is currently fullscreen? |
| 10:55 | <annevk> | I just said the opposite |
| 10:55 | <volkmar> | sorry |
| 10:55 | <volkmar> | i meant, with a js api |
| 10:55 | Von_Davidicus | heads offline. |
| 10:56 | <annevk> | there's window.matchMedia |
| 10:56 | <Von_Davidicus_> | Thanks for the header element info. :) |
| 10:56 | <annevk> | volkmar: http://dev.w3.org/csswg/cssom-view/#dom-window-matchmedia |
| 10:58 | <annevk> | yay foolip |
| 10:59 | <annevk> | one interwebs for foolip please |
| 11:00 | <Ms2ger> | Granted |
| 11:01 | <annevk> | seems I'm gonna take a break for a couple of hours |
| 11:02 | <annevk> | big5 can wait a little |
| 11:03 | <annevk> | volkmar: if you think fullscreen status of a document (other than fullscreen element) needs some kind of convenience attribute please email WHATWG |
| 11:03 | <annevk> | volkmar: I personally think media queries combined wit the API for them are fine, especially since the majority case will be an element fullscreen |
| 11:03 | <annevk> | with* |
| 11:04 | <Ms2ger> | What makes people even publish mixed-encoding pages? |
| 11:44 | <kennyluck> | Can someone give me some examples of invalid URL? |
| 11:44 | <kennyluck> | I know "%" is invalid in IE for one. |
| 13:14 | <annevk> | kennyluck: http://a b/ |
| 13:14 | <annevk> | kennyluck: note the space |
| 13:14 | <annevk> | kennyluck: however, we might make make it so that all URLs can be resolved |
| 13:14 | <annevk> | kennyluck: and that failures happen at the network layer instead |
| 13:15 | <annevk> | kennyluck: kind of depends on the URL work, which MikeSmith is working on and abarth is sometimes |
| 13:15 | <annevk> | I might work on that after Encodings is done, dunno |
| 13:46 | <annevk> | foolip_: hey |
| 13:46 | <foolip_> | annevk, hi |
| 13:46 | <annevk> | foolip_: so those 22 pages where all the pages with bytes in the indicated ranges |
| 13:46 | <annevk> | s/where/were/ |
| 13:47 | <annevk> | foolip_: all the pages with lead bytes under 0xA1 or in the 0xC6-0xC8 region |
| 13:47 | <foolip_> | annevk, do you think that skews the results? |
| 13:48 | <annevk> | not really, those are the ranges for which browsers have incompatible mappings |
| 13:48 | <annevk> | and for which big5 and big5-hkscs have incompatible mappings |
| 13:48 | <annevk> | everything else they agree on so that does not really matter |
| 13:49 | <annevk> | so I think that what you generated is fine |
| 13:49 | <annevk> | and just default to FFFD for the rest |
| 13:49 | <foolip_> | right, I was quite happy to see that the compatible intersection of big5 was a subset of the compatible intersection of big5-hkscs, save one mapping |
| 13:49 | <annevk> | the multiple code point stuff seems hairy though |
| 13:49 | <foolip_> | annevk, spec-wise or implementation-wise? |
| 13:50 | <annevk> | I guess we can special case it if there's only four |
| 13:50 | <foolip_> | The alternative is |
| 13:50 | <foolip_> | PUA |
| 13:50 | <Ms2ger> | Go wash your mouth |
| 13:51 | <annevk> | so |
| 13:51 | <annevk> | <U+00CA,U+0304> Ê̄ |
| 13:51 | <foolip_> | annevk, yes, the official hkscs-2008 mapping listed only those 4 |
| 13:51 | <annevk> | is there no NFC character for that? |
| 13:51 | <foolip_> | annevk, nope, at least not according to python unicodedata |
| 13:51 | <annevk> | we could also FFFD it given that we didn't find it in real usage |
| 13:52 | <foolip_> | It seems better to follow the spec when there is one, don't you think? |
| 13:52 | <foolip_> | or does it create other problems? |
| 13:52 | <foolip_> | I'll see what the surrounding characters were, these 4 seem a bit random... |
| 13:53 | <annevk> | dunno, I don't really have respect for legacy encoding standards and it makes both the encoder and decoder more complicated |
| 13:53 | <foolip_> | annevk, the surrounding characters are also various latin letters with diacritics, so it seems about right |
| 13:53 | <annevk> | so far all encoders work by just passing in one code point at a time and getting back some bytes |
| 13:54 | <annevk> | for this it would need state |
| 13:54 | <foolip_> | can't it just return more bytes? |
| 13:54 | <foolip_> | oh, encoder? |
| 13:55 | <foolip_> | why should we spec an encoder for big5? |
| 13:55 | <annevk> | URLs and <form> |
| 13:55 | <foolip_> | meh, so that's already web-exposed? |
| 13:55 | <annevk> | yes |
| 13:56 | <foolip_> | I'll see if the individual code points can be represented in Big5... |
| 13:57 | <annevk> | we could also not support it in the encoder |
| 13:57 | <annevk> | and if they're not in big5 they would turn into entities in the common case |
| 13:57 | <annevk> | and support them as some kind of special path in the decoder |
| 13:57 | <foolip_> | nope, big5-hkscs has no combining characters it seems, but python does actually support encoding these properly |
| 13:58 | <foolip_> | I would suggest special-casing them and seeing if implementors complain |
| 13:59 | <annevk> | does any browser implementation support them now though? |
| 14:00 | <annevk> | because if they don't, I'm not sure it's worth adding |
| 14:01 | <foolip_> | they all use PUA |
| 14:01 | <annevk> | oh right, except for Opera? |
| 14:01 | <foolip_> | right |
| 14:01 | <foolip_> | specing PUA seems worthwhile avoiding, IMHO |
| 14:02 | <annevk> | fair enough |
| 14:02 | <foolip_> | decoding them correctly seems sensible, for the encoder I'm quite sure just dropping them would do |
| 14:03 | <foolip_> | or what do encoders do with code points that can't be represented? |
| 14:03 | <annevk> | k |
| 14:03 | <annevk> | depends I think |
| 14:03 | <annevk> | form submission makes them entities |
| 14:03 | <annevk> | URLs might use "?" |
| 14:03 | annevk | forgot |
| 14:03 | <annevk> | I haven't really looked at encoders in detail yet |
| 14:03 | <annevk> | there's lots of XXX for encoders |
| 14:03 | <foolip_> | ok, so encoding the first half and escaping the second as an entity might do the job |
| 14:05 | <annevk> | where did you find the HKSCS standard btw? |
| 14:05 | <annevk> | (agreed btw with the encoder suggestion) |
| 14:06 | <foolip_> | annevk, http://www.ogcio.gov.hk/en/business/tech_promotion/ccli/download_area/mapping_table_2008.htm |
| 14:06 | <foolip_> | I also checked it into the git repo |
| 14:08 | <annevk> | k sweet |
| 14:08 | <annevk> | I'll take a stab at updating the big5 algorithm |
| 14:09 | <foolip_> | annevk, great, I'm quite sure this would be an improvement even with the missing mappings |
| 14:09 | <annevk> | foolip_: 8862 => <U+00CA,U+0304> is that a big5.json like index? the 8862 number? |
| 14:09 | <foolip_> | annevk, the bytes \x88\x62, I used the notation in the HKSCS-2008 mapping table there |
| 14:09 | <annevk> | ah |
| 14:10 | <foolip_> | (and in list of missing mappings) |
| 14:10 | <annevk> | right |
| 14:11 | <foolip_> | annevk, I'll have a look at trying to categorize the missing mappings and perhaps asking the Chinese HTML IG if they know more. |
| 14:11 | <foolip_> | happy easter! |
| 14:12 | <annevk> | ah yeah, that might be a good idea |
| 14:12 | <annevk> | you too! |
| 14:12 | <foolip_> | some of the missing mappings smell a lot like they could be de-facto big5 extensions or something |
| 14:12 | <annevk> | oh and btw, we might standardize this through the W3C i18n WG at some point |
| 14:12 | <foolip_> | mkay |
| 14:12 | <annevk> | there's a lot of big5 extensions |
| 14:13 | <annevk> | http://en.wikipedia.org/wiki/Big5 has a bunch on that front |
| 14:13 | <annevk> | http://coq.no/character-tables/chinese-traditional/en too |
| 14:15 | <foolip_> | annevk, thanks, I'll have a look |
| 14:46 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#big5 |
| 14:50 | <davidb> | at |
| 14:50 | <Ms2ger> | mozilla.com? |
| 14:51 | <annevk> | I guess I should fetch that script from foolip |
| 14:52 | <annevk> | generate myself a big5 index |
| 15:17 | <Velmont> | Ms2ger: Ohmy. :-) I should also test it again, -- but I've been on vacation for a while now (still am) -- so don't have my nice setup that I've got at the office. |
| 15:17 | <Ms2ger> | Pff, vacations |
| 15:18 | <Ms2ger> | Those are good to get work done :) |
| 15:18 | <Velmont> | Hehe. -- Well, I managed to fsck up the only two lines I changed, missing a var and actually not doing what I said I should do in an older comment. :S |
| 15:19 | <Ms2ger> | That's better than messing up lines you didn't change |
| 15:19 | <Velmont> | Guess that's true ;} |
| 15:37 | <annevk> | hmm |
| 15:37 | <annevk> | the first 900 or so positions have no mapping |
| 15:38 | <annevk> | weird |
| 15:38 | <annevk> | I now understand why foolip was wondering about that a little more |
| 16:12 | <fkm> | Hi there. I have a problem with the validator not accepting code that is valid according to the specs. The validator tells me that "The text content of element time was not in the required format: The literal did not satisfy the date or time format. <span><time>1991</time> ...de la planète Mars</span>". But according to the specs, the time element accepts "A valid non-negative integer representing a year <time>2011</time>". |
| 16:12 | <fkm> | The page in question is http://dev.snemelk.ch/pages/bonfire/iam/artist.html |
| 16:12 | <fkm> | The specs I have consulted are http://www.w3.org/TR/html5/the-time-element.html and http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element |
| 16:12 | <fkm> | Am I missing something or is this a bug in the validator? I tried validator.w3.org and also the underlying validator.nu to see if the problem is with the implementation by the W3C but both tell me the same thing. |
| 16:15 | <Philip`> | fkm: http://bugzilla.validator.nu/show_bug.cgi?id=913 sounds like it might be relevant |
| 16:16 | <Philip`> | MikeSmith may know |
| 16:17 | <[tm]> | fkm: i think the validator code is not yup to date with the spec |
| 16:18 | <fkm> | Ok. In that case, there is still hope for me yet :-) |
| 16:18 | <fkm> | Thank you both for the feedback! |
| 16:18 | <[tm]> | either file a bug or comment on whatever existing one there might be |
| 16:19 | <[tm]> | time element should really just be dropped |
| 16:19 | <fkm> | I have prepared an email to the W3C validator mailing-list. But I guess I could post it on the validator.nu bug-tracker. |
| 16:19 | <[tm]> | it was a mistake to add it to begin with |
| 16:20 | <[tm]> | fkm: yeah |
| 16:21 | <fkm> | I kind of like the time element. At least more than the new b, i and, u elements ;-) |
| 16:21 | <[tm]> | yeah well |
| 16:21 | <[tm]> | those aren't new |
| 16:21 | <Ms2ger> | annevk, so what are these code points supposed to map to now? |
| 16:22 | <annevk> | Ms2ger: not in a map, they'll become U+FFFD |
| 16:22 | <annevk> | Ms2ger: already implemented in Gecko |
| 16:22 | <Ms2ger> | Oh |
| 16:22 | <Ms2ger> | If I don't need to do anything, go ahead :) |
| 16:22 | <annevk> | well, not sure about trunk |
| 16:22 | <annevk> | did you change encodings already? |
| 16:22 | <Ms2ger> | I haven't changed much lately |
| 16:24 | <fkm> | [tm]: I know. But with HTML5 they have a new, "semantic" meaning. But it is not my place to question the HTML specs. I am too much of a rookie to go there. |
| 16:24 | <Ms2ger> | Hah |
| 16:24 | <Ms2ger> | It's the rookies that need to question the spec |
| 16:24 | <Ms2ger> | Because we all got used to it |
| 16:24 | <fkm> | I will keep that in mind :-) |
| 16:25 | <Ms2ger> | (Not on the meaning of b and i, though... Those have been discussed to death :)) |
| 16:26 | <annevk> | fkm: it's always best to question things, but beware that you might not find logic, especially with web standards |
| 16:26 | <annevk> | I guess I could update my test |
| 16:32 | <[tm]> | if one of you in Belgium or Netherlands is interested in doing a three hour tutorial in Belgium this summer our fall, lemme know |
| 16:32 | <[tm]> | i doubt there is much money involved |
| 16:33 | <[tm]> | if any |
| 16:34 | <[tm]> | Benelux |
| 16:34 | <[tm]> | your Belgian villages have some crazy names |
| 16:35 | <annevk> | Benelux is actually 3 countries |
| 16:35 | <annevk> | not a place |
| 16:35 | <[tm]> | oh |
| 16:36 | <[tm]> | shows WTF i know |
| 16:36 | <annevk> | BElgium/NEtherlands/LUXembourg |
| 16:36 | <[tm]> | ah |
| 16:37 | <[tm]> | Hmm so i guess this is in the Netherlands |
| 16:38 | <[tm]> | +31 |
| 16:39 | <[tm]> | man i can't super the crusade against alcohol |
| 16:41 | <annevk> | yeah that's NL |
| 16:41 | <[tm]> | alcohol is the only thing that makes attending most of these meetings and conferences tolerable |
| 16:42 | <[tm]> | telcons too |
| 16:42 | <TabAtkins> | It does kinda suck when half the conf occurs in bars that are too loud to have good discussion in, but feeling excluded by drinking at all is venturing too far into the "accomodate my personal preferences!" territory. |
| 16:44 | <annevk> | solve all the social problems! |
| 16:45 | <fkm> | Concerning the problem with the validator. Should I add my example as a testcase or an additional comment? |
| 16:45 | <[tm]> | the suggested alternative of after meetings at a coffee shop doesn't really cut it |
| 16:45 | <TabAtkins> | ...huh. I have absolutely no idea what this "Hypertext Layout, Reading Speed and Comprehension" thread is about. |
| 16:46 | <TabAtkins> | (Also he doesnt' use serial comma ARGH) |
| 16:46 | <TabAtkins> | As far as I can tell, someone decided to just collect a bunch of articles and say "Hey, these articles describe things vaguely related to what CSS3 Text cares about. Enjoy!". |
| 16:46 | <[tm]> | that's like going to an AA meeting |
| 16:47 | <[tm]> | TabAtkins: is that from the www-style list? |
| 16:47 | <TabAtkins> | Yes. |
| 16:48 | <[tm]> | i think you're the only one still subscribed to that list |
| 16:48 | <TabAtkins> | hahaha |
| 16:48 | <hober> | not the only one |
| 16:49 | <[tm]> | ok two of you |
| 16:51 | <[tm]> | hober: btw you rock mightily for fighting the good fight on html WG CPs |
| 16:51 | <TabAtkins> | Indeed. |
| 16:51 | <TabAtkins> | I gave up. |
| 16:51 | <TabAtkins> | Not worth the effort when it's a coin-toss anyway. |
| 16:52 | <[tm]> | no comment |
| 16:52 | <[tm]> | expletive deleted |
| 16:54 | <hober> | [tm]: thanks! sometimes i think i'm the only one who takes seriously the charter requirement to seek convergence with the whatwg |
| 16:55 | <annevk> | Ms2ger: http://dump.testsuite.org/encoding/single-byte-test.html seems not much has landed |
| 16:56 | <Ms2ger> | Sounds right |
| 16:57 | <eseidel> | Ms2ger: what about feature strings? |
| 16:58 | <Ms2ger> | eseidel, we'd like to put a static list in DOM4 |
| 16:58 | <Ms2ger> | And then lock the door and throw away the key |
| 16:58 | <TabAtkins> | Yes omg |
| 16:59 | <annevk> | http://wiki.whatwg.org/wiki/DOM_features has a start |
| 17:00 | <eseidel> | Ms2ger: I support |
| 17:01 | <hober> | yes, feature strings need to DIAF |
| 17:01 | <eseidel> | TabAtkins: ideally would like to only return YES for things which are requried for web compat |
| 17:01 | <Ms2ger> | Can either of you fill in the blanks for WebKit? :) |
| 17:01 | <eseidel> | Ms2ger: and NO for everythgin else |
| 17:01 | <Ms2ger> | Agreed |
| 17:01 | <TabAtkins> | Yeah. |
| 17:02 | <Ms2ger> | But first, data! :) |
| 17:02 | <eseidel> | Ms2ger: http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMImplementation.cpp#L220 |
| 17:03 | <eseidel> | Ms2ger: but it should be very very easy to write some simple js to test |
| 17:03 | <Ms2ger> | On the wiki! ;) |
| 17:03 | <eseidel> | Ms2ger: sorry, wiki's and I don't get along :) |
| 17:03 | <eseidel> | I'm a reader, not a writer :p |
| 17:04 | <annevk> | that is prolly sufficient |
| 17:05 | <annevk> | i'll just dump the link in the wiki |
| 17:06 | <Ms2ger> | eseidel, I love how it builds a hashset in isEvents3Feature, for one string :) |
| 17:07 | <annevk> | whoa, SVG went nuclear with features |
| 17:08 | <annevk> | what kind of code did they expect authors to write? |
| 17:08 | <Ms2ger> | Well |
| 17:08 | <shepazu> | annevk: huh? |
| 17:08 | <Ms2ger> | You can use them from markup too, iirc |
| 17:08 | <TabAtkins> | Yeah, the feature strings are used in <switch> |
| 17:12 | <eseidel> | Ms2ger: this is performance critcal code you're readnig here |
| 17:12 | <eseidel> | Ms2ger: we have our best men on it |
| 17:12 | <eseidel> | Ms2ger: namely, me. :) (I think I wrote that section) |
| 17:13 | <Ms2ger> | Ah, so that's why we're winning the browser wars ;) |
| 17:14 | <eseidel> | oh, I just thought we were all singing kareoke at the local browser pub |
| 17:14 | <eseidel> | (and SVG was drunk in the corner, spouting about fonts and feature strings) |
| 17:14 | <Ms2ger> | Then I'd feel excluded :( |
| 17:14 | <Ms2ger> | They don't like letting AIs into bars... |
| 17:14 | <TabAtkins> | You and bz can go have AI fun somewhere. |
| 17:14 | <TabAtkins> | (Pretty sure the thing I met at SXSW was just a skinvelope controlled by bz.) |
| 17:15 | <Ms2ger> | We've done that enough when he was building me |
| 17:16 | <Ms2ger> | Also, TabAtkins, when are you going to write the box tree spec? :) |
| 17:17 | <TabAtkins> | After I write the parsing spec, which I'm in the middle of right now. |
| 17:17 | <TabAtkins> | Or actually, roughly in the beginning, but still. |
| 17:20 | <[tm]> | He refused to accept vice in exchange for his lulz |
| 17:25 | <annevk> | shepazu: just that has so many |
| 17:25 | <annevk> | TabAtkins: kind of jealous now |
| 17:27 | <annevk> | "WAI-Engage is an open forum for responsive development of material |
| 17:27 | <annevk> | supporting web accessibility, including support for Web Accessibility |
| 17:27 | <annevk> | Initiative (WAI) resources." |
| 17:27 | <annevk> | I don't even know what that means... |
| 17:41 | <Ms2ger> | TabAtkins, including zcorpan's quirks stuff? |
| 17:42 | <TabAtkins> | Ms2ger: Um, sure! |
| 17:42 | TabAtkins | has to actually look at that spec. |
| 17:45 | <moo-_-> | I have this really ambitious idea: I'd like that sites could suggest color and background colour for tabs besides the site icon. I know it's not going to happen very easily, but if it were to happen how I should take this idea forward. creating chrome + ff add-ons supporting this, promoting them like mad and then hope it is adopted by the browsers themselves some point? |
| 17:46 | <moo-_-> | this would be mostly for usability. add-ons like colorfultabs do this already, but you need to manually configure in the sites. |
| 17:46 | <TabAtkins> | That sounds like a bad idea that I would hate. |
| 17:47 | <jamesr> | TabAtkins: "That's a bad idea. You should feel bad." |
| 17:47 | <Philip`> | Sounds like it should be as popular as IE's scrollbar colouring CSS |
| 17:47 | <TabAtkins> | Well, moo-_- shouldn't feel bad. I'm just saying, I would hate it. |
| 17:47 | <TabAtkins> | And since I'm clearly representative of all users... |
| 17:47 | <jamesr> | Philip`, you mean WebKit's? IE has that too? |
| 17:47 | <TabAtkins> | Pretty sure we copied IE there. |
| 17:48 | <moo-_-> | TabAtkins: ok, let me ask then is there anything we could do to make tabs / windows / bookmarks / etc. more distinctive besides their favicon? |
| 17:48 | <Philip`> | jamesr: http://www.javascriptkit.com/howto/scrollbarcolor.shtml |
| 17:48 | <moo-_-> | like all slashdot.org tabs would have (non-offending) green background |
| 17:49 | Philip` | didn't realise WebKit had done it |
| 17:49 | <jamesr> | Philip`, WebKit has pseudoes |
| 17:49 | <annevk> | moo-_-: there are some extensions for that |
| 17:49 | <jamesr> | http://www.webkit.org/blog/363/styling-scrollbars/: |
| 17:49 | <moo-_-> | annevk: I am aware of that |
| 17:49 | <annevk> | given that Apple tries to get rid of the scrollbar creating pseudos for that was a silly idea |
| 17:50 | <moo-_-> | annevk: but my point was more like that websites themselves could suggest the colours |
| 17:50 | <moo-_-> | hmm |
| 17:50 | <annevk> | moo-_-: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F |
| 17:50 | <annevk> | moo-_-: might help |
| 17:50 | <moo-_-> | annevk: thanks |
| 17:50 | <moo-_-> | this is a starting point, at least |
| 17:50 | <moo-_-> | :) |
| 17:50 | <annevk> | moo-_-: if there's interest from authors, browser UI people, no phishing problems, no security problems, it might have a chance... |
| 17:51 | <annevk> | moo-_-: but I doubt it somewhat |
| 17:51 | <annevk> | moo-_-: the extension could use some information from the page as a hint for the color |
| 17:52 | <dglazkov> | good ${time_of_day}, Whatwg! |
| 17:53 | <moo-_-> | annevk: yep. my first idea was to have (all) extension authors to agree on some way to extract this information from HTML <head> <meta> |
| 17:57 | <annevk> | moo-_-: fwiw, Opera has this experimental thing with just having large tabs that show thumbnails of the pages |
| 17:57 | <annevk> | I don't use it because I have a smallish screen, but it has some potential I think |
| 17:58 | <moo-_-> | annevk: I tried that feature... nice but takes little screen estate |
| 17:58 | <moo-_-> | annevk: IE9 + Win8 also do this tab bar thumbnail thing |
| 17:58 | <moo-_-> | but it is not good for visually grouping which pages came from which sites |
| 17:58 | <moo-_-> | you still need to "read" thumbnails |
| 18:01 | <Ms2ger> | Good, dglazkov |
| 18:01 | <dglazkov> | ${time_of_day | "morning"} |
| 18:16 | <annevk> | hsivonen: I like how it says "Note: I’ve also added the prefixes versions –moz, –webkit & –o for Mozilla, Webkit & Opera to be compatible with the other browsers. Never forget to do the same!" and then continues to just do that |
| 18:16 | <annevk> | hsivonen: but it's better than most browser advocacy |
| 18:22 | <TabAtkins> | Hrm. I always forget what the \237 indicates in the CSS syntax definition of "non-ascii". |
| 18:22 | <TabAtkins> | (Defined as [^\0-\237].) |
| 18:22 | <annevk> | octal |
| 18:23 | <annevk> | which is 159 or 0x9F |
| 18:23 | <annevk> | iirc |
| 18:24 | <TabAtkins> | Yeah it is. I just don't understand what the significance of 0x9f is. |
| 18:24 | <TabAtkins> | Oh, I was looking at an extended ascii chart, not at unicode. |
| 18:25 | <TabAtkins> | A0 is where the real characters start again. |
| 18:25 | <annevk> | it should be 0x7F |
| 18:25 | <annevk> | well dunno |
| 18:25 | <annevk> | CSS is weird |
| 18:25 | <TabAtkins> | 0x80 to 0x9F are all non-printable control characters. |
| 18:25 | <TabAtkins> | So I guess it's sensical to cut those out too. |
| 18:25 | <TabAtkins> | But it's not really "non-ascii" then. ^_^ |
| 18:26 | <annevk> | well yeah, and there's a ton of other code points that are not actually "usable" |
| 18:26 | <TabAtkins> | Yeah. |
| 18:26 | <TabAtkins> | I'm guessing it was just a useful block to cut out, since it's adjacent to the ascii block. |
| 18:26 | <annevk> | I can already see them discussing this in a committee meeting |
| 18:27 | <annevk> | that's actually a rather funny thought |
| 18:28 | <TabAtkins> | hehe |
| 18:29 | <annevk> | only one decoder to go |
| 18:29 | <annevk> | never imagined it would take this long, but it's starting to look pretty neat |
| 18:33 | <TabAtkins> | Huh. Why is parsing so complicated? |
| 18:33 | <Hixie> | dialog.show()/showModal() or dialog.open()/openModal()? I was going to use show() but the convention is to have a close() method and onclose handler |
| 18:33 | <TabAtkins> | It looks a lot easier when you use a grammar. |
| 18:33 | <TabAtkins> | Using "open" has an interesting parallel with <details open> |
| 18:34 | <Hixie> | we are going to have <dialog open> |
| 18:34 | <Hixie> | maybe that's a good reason not to use open() |
| 18:34 | <Hixie> | it would clash with the IDL attribute reflecting open="" |
| 18:34 | <Hixie> | looks like most APIs use showModal() |
| 18:34 | <Hixie> | as opposed to openModal() |
| 18:35 | Hixie | decides to stick with show |
| 18:35 | <annevk> | TabAtkins: yeah, CSS parsing is vastly more complicated than it needs to be |
| 18:35 | <annevk> | TabAtkins: mostly because of the grammar and nobody looking at handwriting a tokenizer |
| 18:36 | <Hixie> | css parsing is also complicated because the grammar didn't define any of the error handling |
| 18:37 | <Hixie> | so the error handling became semi-random, like html's |
| 18:37 | <Hixie> | (well, it defined some error handling, but only within the "forward-compatible grammar" set) |
| 18:38 | <TabAtkins> | annevk: Really, the complication is just that it's an ad-hoc grammar with lots of options at a lot of points, rather than the relatively simply HTML grammar (ignoring quirks and scripts). |
| 18:38 | <Hixie> | good thing i wasn't drinking anything when i read _that_ |
| 18:38 | <TabAtkins> | Hixie: Dude, go look at your description of the types of tokens. There's, like, 5 of them. |
| 18:39 | <Hixie> | ignoring quirks and scripts it's pretty simple, i agree :-) |
| 18:41 | <annevk> | I especially hate that escapes can occur everywhere |
| 18:42 | <annevk> | I would have removed that in 2000, if I was smarter back then |
| 18:44 | <Ms2ger> | Oh man |
| 18:44 | <Ms2ger> | If I had a time machine... |
| 18:45 | <Ms2ger> | Killing Hitler? Nah, I'd lock Bert and howcome in a room for a few hours |
| 18:45 | <TabAtkins> | ...I'd create a Turing oracle and break open computation levels, brute-forcing my way to immediate godlike-AI. |
| 18:45 | <Hixie> | hah |
| 18:46 | <TabAtkins> | (And then be killed by it, because its value system doesn't recognize life as a useful thing.) |
| 18:46 | <TabAtkins> | (Or as a "thing" at all.) |
| 18:53 | <Hixie> | options for aligning these dialogs... use aps pos and define the static position as one that happens to result in the alignment i want; define that the element is in a positioning regime that ignores 'position' and 'float'; invent a new 'position' keyword that works like 'relative' but starts with the appropriate alignment rather than the static position (that one is harder since from CSS the new keyword would be useless without a way to define the link from one e |
| 18:57 | <Hixie> | hmm |
| 18:58 | <TabAtkins> | That cut off at "from one el" for me. |
| 19:00 | <Hixie> | from one element to another |
| 19:01 | <Hixie> | should it be possible to turn a <dialog> that's already open into a modal dialog? or should .showModal() do nothing or throw an exception if it is already open? |
| 19:01 | <TabAtkins> | So, the element() function provides a way to link one element to another. But right now it's defined to only take an id selector. |
| 19:02 | <Hixie> | (and should the answer be different if it's open and modal or open and not modal?) |
| 19:02 | <Hixie> | TabAtkins: the link between the elements is given by the argument to the show() method, it's not in CSS |
| 19:02 | <TabAtkins> | Hixie: Okay, so it's magic from CSS's perspective. That's fine. |
| 19:02 | <Hixie> | right |
| 19:03 | <Hixie> | i'm just saying a new keyword would be kinda silly since there'd be no good way to use it in other contexts |
| 19:03 | <Hixie> | new position keyword |
| 19:03 | <Hixie> | i'm thinking either these elements should be forced into a new regime, or i should just use abs pos with a redefined static position |
| 19:03 | <TabAtkins> | Actually, I think you should just define a new position value. |
| 19:04 | <Hixie> | what would it mean if used on a random div? |
| 19:04 | <TabAtkins> | It's just as magic, but it can be picked up by CSS later. |
| 19:04 | <TabAtkins> | I'm thinking it woudl be equivalent to 'relative'. |
| 19:05 | <Hixie> | could work |
| 19:06 | <Hixie> | hmm |
| 19:06 | <Hixie> | how do i have a different rule for dialogs that were given an alignment system and dialogs that should just center themselves? |
| 19:06 | <Hixie> | could be magic, i suppose |
| 19:06 | <TabAtkins> | Magic for now. |
| 19:06 | <TabAtkins> | I'll review after you lay down some text. |
| 19:07 | <TabAtkins> | To make sure it's not hostile to what I want to do with 'position'. |
| 19:07 | <TabAtkins> | Lunch now to grab an interview candidate. |
| 19:07 | <Hixie> | hehe |
| 19:07 | <Hixie> | later |
| 19:15 | <annevk> | http://www.w3.org/2012/02/timed-text-wg-charter |
| 19:15 | <annevk> | o_O |
| 19:15 | <Ms2ger> | Wow |
| 19:15 | <annevk> | "A Section Edition of the Timed Text Markup Language (TTML) 1.0 Recommendation" |
| 19:15 | <Ms2ger> | LC: N/A |
| 19:16 | <Ms2ger> | CR: N/A |
| 19:16 | <Ms2ger> | PR: N/A |
| 19:16 | <Ms2ger> | Rec: November 2012 |
| 19:16 | <annevk> | boom |
| 19:16 | <annevk> | headshot |
| 19:16 | <Hixie> | why "o_O" ? |
| 19:17 | <Hixie> | it's pretty normal for wgs to have their charters extended like this... |
| 19:17 | <Hixie> | (by "normal" i mean "common place" not "sensible") |
| 19:17 | <Ms2ger> | Well, charters |
| 19:17 | <Ms2ger> | The former was already ruled out |
| 19:18 | <annevk> | given https://www.w3.org/2000/09/dbwg/details?group=34314 it's highly surprising this is being extended |
| 19:18 | <annevk> | the o_O was for W3C continuing to put effort into something the community is not really behind |
| 19:18 | <Hixie> | um... |
| 19:18 | <Hixie> | the w3c does that all the time |
| 19:18 | <Hixie> | for some definition of "community" |
| 19:18 | <Hixie> | e.g. rdf... |
| 19:19 | <Ms2ger> | Heh, I don't think I've seen "not in good standing" before |
| 19:20 | <annevk> | Hixie: true, this feels a bit different, more like another XHTML 2.0 group |
| 19:21 | <annevk> | maybe I should reply with some comments |
| 19:22 | <Hixie> | xhtml2 lasted years past the point of the community not being really behind it |
| 19:22 | <Hixie> | xforms' charter only ran out last month |
| 19:23 | <Hixie> | (and their timeline has dates until september 2012, so i doubt they'll be closed) |
| 19:23 | <Hixie> | just let the group do it's stuff, the alternative is they come and try to force their ideas into our stuff :-P |
| 19:23 | <Hixie> | its |
| 19:25 | <Ms2ger> | (Also, for the interested people without member access: https://www.w3.org/2000/09/dbwg/details?group=34314&public=1) |
| 19:25 | <annevk> | ah thanks Ms2ger, didn't know that was available |
| 19:26 | <Ms2ger> | "The participants list is available publicly" |
| 19:26 | <Ms2ger> | 4th bullet |
| 19:26 | <annevk> | Hixie: fair enough |
| 19:27 | <annevk> | Ms2ger: fascinating |
| 19:27 | <Ms2ger> | No kidding |
| 19:44 | <fkm> | I have another question about the validator. I am not sure if I understood the concept of flow and phrasing content correctly. The way I understand it, flow content is the same as block elements and phrasing content is the same as inline elements or innerHTML. Following this reasoning having inline elements as direct descendants of the body should not be valid. But the validator does not complain. |
| 19:44 | <fkm> | Here's an example: http://dev.snemelk.ch/tests/html5-content_model.html |
| 19:44 | <fkm> | Is there a flaw with my reasoning or is this another bug (out of sync problem) in the validator? |
| 19:46 | <annevk> | you should read the definitions more carefully probably |
| 19:46 | <fkm> | Ok. I will do that :-) Thank you! |
| 19:47 | <annevk> | and try to forget about block/inline-level |
| 19:48 | <fkm> | I will try. But old habits die hard ;-) |
| 19:51 | <Hixie> | fkm: to find out what is allowed in <body>, go to the body element's definition in the spec, and check it's "content model" description |
| 19:51 | <Hixie> | fkm: follow the links from that to see what the terms mean |
| 19:52 | <fkm> | Ok |
| 19:52 | fkm | has much to learn :-) |
| 19:52 | <fkm> | Thank you both for the pointers! |
| 21:58 | <zewt> | heh, gmail's gui editor has become next to unusable |
| 21:58 | <zewt> | delete one line of quotes, the entire block disappears |
| 22:00 | <TabAtkins> | Solution: stop using a gui editor. |
| 22:01 | <TabAtkins> | Or use the gui editor in the way most people do, bottomquoting the entire preceding message. |
| 22:01 | <zewt> | that's too much of a pain in the ass with gmail, because if you don't send the mail in gui mode, it sends a horribly pre-wrapped 80-column mail |
| 22:02 | <zewt> | so i'd have to switch back and forth each time (or manually formatting-kill every time) |
| 22:04 | <Hixie> | pine. |
| 22:05 | <zewt> | gross |
| 22:05 | <zewt> | i think i used that in highschool, heh |
| 22:05 | <Hixie> | that's what i use for all my e-mail. :-) |
| 22:06 | <zewt> | that must be why it takes you six months to reply to mail :P |
| 22:06 | <Hixie> | nah, it's the other way around |
| 22:06 | <Hixie> | it'd be longer with a gui editor |
| 22:14 | TabAtkins | just realized he doesn't have to match the grammar exactly with his parser; he just has to capture the same behavior. |
| 22:14 | <TabAtkins> | Duh. |
| 22:16 | <TabAtkins> | In particular, the grammar goes through some contortions to express things like "selectors can be basically anything!" and to produce a good structure for error-recovery. |
| 22:36 | <Hixie> | heycam|away: you should provide a spec subscription model for webidl like i have for html :-) |