| 00:39 | <MikeSmith> | Hixie, for future reference, on Debian Linux systems at least, the SPECIAL part of /usr/share/i18n/locales/iso14651_t1_common seems to be what ends up controlling collation for common symbols |
| 00:39 | <MikeSmith> | ...and uncommon ones, too |
| 00:51 | <MikeSmith> | .. |
| 00:51 | <MikeSmith> | Just now hearing the news about Steve Jobs |
| 06:31 | <hsivonen> | Hixie: does http://html5.org/tools/web-apps-tracker?from=6642&to=6643 have an effect on what the parser does? the "special" group is used for parsing, but does it matter in this case? |
| 06:33 | <Hixie> | i believe the answer is no, because they're void elements |
| 06:33 | <Hixie> | so in a sense we could have instead removed the void elements from the list |
| 06:34 | <hsivonen> | ok |
| 06:34 | <Hixie> | which i guess in a naive implementation might improve perf |
| 06:34 | <Hixie> | but in practice i presume everyone uses bits on the tag type id so it doesn't matter |
| 08:32 | Dashiva | wonders if <title> will soon become optional, what with browser after browser removing the title bar |
| 09:25 | <jgraham> | Am I missing something, or is there no ambiguity at all in the interpretation of a string in the proposed .create() format? A string at the strat of a lsit is always a tag name. A bare string is always a text node. |
| 09:25 | <jgraham> | *start |
| 09:25 | <jgraham> | (also *list, but that is easier) |
| 09:27 | <annevk> | inside a list that is true |
| 09:27 | <annevk> | the problem is with a list of lists, but we can avoid that I think |
| 09:28 | <jgraham> | Where would there be a list of lists? |
| 09:29 | <annevk> | it depends on how the overall design turns out |
| 09:30 | <jgraham> | Well yes… obviously |
| 09:30 | <annevk> | i think we can avoid it by having varargs |
| 09:32 | <jgraham> | Indeed |
| 13:01 | <hsivonen> | http://www.glazman.org/weblog/dotclear/index.php?post/2011/10/05/a-HTML-Spaghetti-Western%3A-The-Serializer-The-Parser-and-The-Ugly-Blank-Lines |
| 13:35 | <annevk> | hsivonen, he's having that fight with everything that defines an object model |
| 13:35 | <annevk> | hsivonen, e.g. CSS |
| 13:36 | <annevk> | an object model throws away information an editor needs, such as whitespace between attributes, order of attributes, etc. |
| 13:36 | <annevk> | I'm not sure why he can't accept that if you build a WYSIWYG editor that also has some kind of source editing you have to build a custom solution |
| 13:49 | <MikeSmith> | hsivonen: validator.nu enhancement request from Jukka! |
| 13:57 | <karlcow> | annevk: why? The choice could be just to have some rules for a certain class of products to ensure interop in between editors. |
| 14:00 | <hsivonen> | karlcow: it's more complicated than that |
| 14:00 | <hsivonen> | karlcow: depending on what level of source preservation you want |
| 14:00 | <hsivonen> | karlcow: for example, the DOM doesn't store the whitespace that was between attributes |
| 14:01 | <karlcow> | hsivonen: so you mean in case you do a round-trip browser/editor |
| 14:01 | <hsivonen> | karlcow: so when writing an editor, one should decide up front if it's going to be a DOM editor or a source-fidelity editor |
| 14:01 | <hsivonen> | karlcow: if you are using the DOM as the model but try to make a source-fidelity editor, there's going to be pain |
| 14:01 | <karlcow> | I guess humans are dealing with the physical organization of the markup not the dom |
| 14:02 | <hsivonen> | karlcow: I mean round-tripping aspects of the source that browsers consider meaningless or errors |
| 14:03 | <hsivonen> | I don't know how Dreamweaver does it, but clearly, they've designed for it from day 1 |
| 14:03 | <jgraham> | I feel quite sorry for glazou really. He seems to be doing something hard and not that interesting with technology that makes it even harder. |
| 14:12 | <hsivonen> | jgraham: I think editors are interesting and having DOM-based editors is worthwhile |
| 14:13 | <hsivonen> | jgraham: the problem is when user expections don't match the realities of the editor being DOM-based |
| 14:13 | <jgraham> | hsivonen: I don't mean uninteresting as a problem space |
| 14:13 | <jgraham> | I mean "not a product many people are interested in" |
| 14:14 | <jgraham> | At least my perception is that that age of the dreamweaver-style editor is ending |
| 14:14 | <jgraham> | My perception could be wrong of course |
| 14:14 | <jgraham> | But I expect that on the low end people are going to use online contentEditable based tools |
| 14:15 | <jgraham> | and at the high end they will use either a text editor or some more fancy falsh-like thing that totally abstracts away the underlying markup |
| 14:15 | <hsivonen> | jgraham: why would Dreamweaver-style be ending? |
| 14:15 | <jgraham> | *flash |
| 14:15 | hsivonen | doesn't know of other Dreamweaver-style editors than Dreamweaver itself |
| 14:16 | <jgraham> | Isn't BlueGriffon dreamweaver-style? |
| 14:16 | <hsivonen> | jgraham: not in my opinion :-) |
| 14:16 | <jgraham> | Why not? I am curious |
| 14:17 | <hsivonen> | jgraham: because it doesn't preserve errors in the parts of source that you aren't editing on the visual side |
| 14:17 | <jgraham> | Hmm, that is quite a technical distinction |
| 14:17 | <hsivonen> | jgraham: I believe that's a key selling point of Dreamweaver to a part of its audience |
| 14:17 | <jgraham> | In terms of markets I think they occupy a similar space |
| 14:18 | <hsivonen> | jgraham: I think Dreamweaver's feature set could serve also the market that BlueGriffon's feature set can serve |
| 14:18 | <hsivonen> | jgraham: but not vice versa in the general case |
| 14:18 | <jgraham> | Right, it might not be as good as dreamweaver (in some respects), but it competes with it |
| 14:19 | <hsivonen> | jgraham: as I understand it, source preservation has been a marketable and marketed feature of Dreamweaver since forever |
| 14:19 | <hsivonen> | jgraham: so BlueGriffon doesn't have one of the key features of Dreamweaver |
| 14:20 | <hsivonen> | jgraham: when BlueGriffon tries to approximate that feature of Dreamweaver, there's pain |
| 14:20 | <jgraham> | Making a product that lacks a key feature of the market leader for deep technical reasons in a market that I claim is being squeezed doesn't make my feel like BlueGriffon is in a *better* position than I previously believed :) |
| 14:20 | <jgraham> | uh, that sentence changed focus half way through |
| 14:24 | <annevk> | karlcow, "some rules" you gonna write them up? ;) |
| 14:24 | <karlcow> | annevk: unrelated. |
| 14:25 | <hsivonen> | karlcow: in the CSS parsing and CSSOM case, throwing away unsupported rules is part of the fundamental operation of the CSS forward-compatible parsing rules |
| 14:26 | <hsivonen> | karlcow: yet, if you want Dreamweaver's source preservation features, you need not to throw away unsupported rules |
| 14:26 | <karlcow> | yup, understood, different class of products. |
| 14:27 | <hsivonen> | right, but there's really no need to standardized the internal data model of Dreamweaver, because it's not exposed to Web content |
| 14:27 | <hsivonen> | s/zed/ze/ |
| 14:27 | <karlcow> | parsing for rendering and editing are two different use cases |
| 14:28 | <karlcow> | hsivonen: agreed. exposed to humans for web editing |
| 14:28 | <karlcow> | usability space |
| 15:29 | <annevk> | you can't just wave "classes of products" around as a magic wand and solve problems karlcow |
| 15:32 | karlcow | is still looking for his magic wand without understanding annevk |
| 15:34 | <jgraham> | annevk: (I don't think karlcow was trying to solve the problem so much as understand it) |
| 15:35 | <karlcow> | thanks jgraham :) |
| 16:08 | <FlorianX> | annevk: did you get the tweet? :-) |
| 16:15 | <annevk> | I did |
| 16:16 | <FlorianX> | ok |
| 16:26 | <bga_> | TabAtkins in var example slide $main-color$. Is it error? |
| 16:27 | <jgraham> | annevk: Should have answered on Google Plus |
| 16:28 | <annevk> | ? |
| 16:31 | <jgraham> | Well if the question "did you get the tweet" is asked on irc, not using a third means of communication to reply is lame |
| 16:31 | <annevk> | i'm boring, remember? |
| 16:40 | <timeless> | heh |
| 16:43 | <jgraham> | annevk: So you're having bacon cheeseburger and yoghurt this evening? |
| 16:45 | <MikeSmith> | about video@controls, why does it not make more sense for the video play/pause/etc. buttons to be displayed by default? |
| 16:45 | <MikeSmith> | so in that case, the controls attribute would be more like spellcheck |
| 16:46 | <MikeSmith> | that is, you'd only need to specify it when you didn't want the controls displayed |
| 16:46 | <annevk> | jgraham, not sure about dinner, but I had delicious yoghurt |
| 17:15 | <karlcow> | "Tolerating broken HTML writers" http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Connolly/tolerated.html |
| 17:16 | <karlcow> | " Please stop generating HTML in this style!" :) |
| 17:17 | <karlcow> | also http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Connolly/errors.html |
| 17:48 | <Ms2ger> | MikeSmith, I believe the argument was that <video nocontrols> would be used by people with JS-based controls, and these would break when you disable JS |
| 17:48 | <MikeSmith> | I see |
| 18:03 | <Hixie> | MikeSmith: specifically, the lack of a controls="" attribute doesn't mean there's no controls |
| 18:03 | <Hixie> | MikeSmith: it has to be no controls="" attribute _plus_ JS disabled |
| 18:03 | <MikeSmith> | OK |
| 18:04 | <Hixie> | also, even with JS enabled, there can (should) still be controls e.g. in the context menu |
| 18:11 | <MikeSmith> | ah, yeah |
| 18:15 | <timeless> | anyone here know how to get to the Desktop version of google calendar? |
| 18:15 | timeless | hates sites that do discrimination |
| 20:02 | <rburton> | would this be a good place to get webidl help? |
| 20:14 | <timeless> | rburton: what's wrong? |
| 20:15 | <rburton> | just new to it mainly |
| 20:15 | <rburton> | is there a good tutorial/annotated reference? |
| 20:15 | <rburton> | but the main point is, i want an interface that has a string "uri" attribute, and a unlimited string-string hash "params" attribute |
| 20:15 | <rburton> | the spec seems to say that i can't do the hash bit |
| 20:16 | <timeless> | hash? |
| 20:16 | rburton | this appears to parse widlproc dictionary Options {}; interface ShareItem { attribute DOMString uri; attribute Options options; }; |
| 20:16 | rburton | just discovered a new keybinding in irccloud |
| 20:17 | <timeless> | tab? :) |
| 20:17 | <rburton> | control-enter makes a /me |
| 20:17 | <timeless> | btw, do you have a spare invite for irccloud? |
| 20:17 | <rburton> | sure |
| 20:17 | <rburton> | email? |
| 20:17 | <timeless> | timeless@gmail |
| 20:17 | <rburton> | sent |
| 20:17 | <timeless> | thanks! |
| 20:18 | <rburton> | so in js i want an object with a "uri" string attribute, and a plain object "options" attribute that can contain arbitrary key-value pairs |
| 20:18 | <rburton> | but id like to do it "properly" in webidl so there are sane docs for that arbitrary bit |
| 20:21 | <timeless> | offhand, it seems that webidl could definitely use some more text explaining how it expects things to be used, and especially whether it covers this use case |
| 20:21 | <timeless> | i believe it does, but it seems like reasonable feedback to send to the list |
| 20:21 | timeless | tries to use irccloud.com from a Torch |
| 20:27 | <timeless> | shiny! |
| 20:27 | <rburton> | timeless: what is the best list for webidl feedback? |
| 20:27 | <Hixie> | webapps |
| 20:27 | <Hixie> | public-webapps⊙wo |
| 20:28 | <Hixie> | (it should say at the top of the webidl spec) |
| 20:28 | <timeless> | Hixie: should; doesn't :( |
| 20:29 | <timeless> | also good feedback :) |
| 20:31 | <timeless> | sorry |
| 20:31 | timeless | is getting the hang of irccloud |
| 20:40 | <AryehGregor> | "Palpable"? Really? |
| 20:40 | <timeless> | AryehGregor: context? :) |
| 20:40 | <AryehGregor> | timeless, html5.org/r/6640 |
| 20:41 | <Hixie> | AryehGregor: you got a better word? :-) |
| 20:41 | <Hixie> | i'm running out of unique terms here |
| 20:41 | <rburton> | hehe |
| 20:41 | <rburton> | Hixie: thanks |
| 20:43 | <timeless> | heh |
| 20:44 | <timeless> | "Experiential"? :) |
| 20:48 | <Hixie> | too confusingly close to "experimental" |
| 20:49 | <Philip`> | If the conformance model is too complex to even come up with reasonable terms to describe it to people, maybe the model should be simplified, e.g. by removing the whole palpability should-level requirement entirely :-) |
| 20:50 | <timeless> | nah :) |
| 20:50 | <timeless> | Hixie: yeah, understood |
| 20:51 | <Hixie> | Philip`: i considered it, and may still do that. i think at a minimum it provides an interesting view into the language for our own purposes of sanity checking things. |
| 20:51 | <Hixie> | the requirement itself is essentially just an evolution of HTML4's "paragraphs musn't be empty" rule |
| 20:52 | <astearns> | evident? |
| 20:56 | <AryehGregor> | Does IE not support innerHTML on tbody or something crazy like that? |
| 20:56 | <Hixie> | astearns: considered it, but its meaning is a little too much on the side of "obvious" than just "visible" |
| 20:56 | <AryehGregor> | . . . |
| 20:56 | <timeless> | AryehGregor: http://ajaxian.com/archives/innerhtml-gotchas |
| 20:57 | <timeless> | > After some searching it seems IE has inconsistent support for the insertAdjacentHTML method, and apparently for elements like TR and TBODY IE will throw an exception if the method is called on those methods. |
| 20:57 | <AryehGregor> | Wow, that's insane. |
| 20:57 | <timeless> | > We can read about this on good ‘ole MSDN: innerHTML property. |
| 20:57 | <timeless> | The important piece is: |
| 20:57 | <timeless> | The property is read/write for all objects except the following, for which it is read-only: COL, COLGROUP, FRAMESET, HTML, STYLE, TABLE, TBODY, TFOOT, THEAD, TITLE, TR. |
| 20:57 | <AryehGregor> | I hate IE. |
| 20:57 | <timeless> | of course, that link is dead |
| 20:58 | <timeless> | yay msdn |
| 20:58 | <AryehGregor> | http://msdn.microsoft.com/en-us/library/ms533897(v=vs.85).aspx |
| 20:58 | <timeless> | right, the comment at the end: |
| 20:58 | <timeless> | > "The property is read/write for all objects except the following, for which it is read-only: COL, COLGROUP, FRAMESET, HEAD, HTML, STYLE, TABLE, TBODY, TFOOT, THEAD, TITLE, TR." |
| 20:58 | timeless | wonders how it got lost from the body of the document |
| 20:59 | <timeless> | it's possible they removed that restriction by 10? |
| 20:59 | <timeless> | which vers of ie are you testing? |
| 20:59 | timeless | has ie10 previews available if there's a testcase |
| 20:59 | timeless | is *way* too lazy to write one |
| 21:01 | <AryehGregor> | 9. |
| 21:21 | <jgraham> | Ms2ger: So why does WebIDL put attributes on prototypes? That doesn't seem to match non-gecko browsers or be very logical |
| 21:28 | jgraham | thinks we should introduce papal conformance conditions |
| 21:28 | timeless | sighs |
| 21:28 | timeless | read paypal] |
| 21:32 | <jgraham> | timeless: It's OK, so does google |
| 21:32 | <timeless> | oh, i feel much better now, thanks :) |
| 21:46 | <Ms2ger> | jgraham, I can only read the spec and complain when Gecko fails tests for matching it :) |
| 21:46 | Ms2ger | doesn't claim to understand WebIDL |
| 21:47 | <timeless> | heh |
| 22:04 | <jgraham> | Ms2ger: Dammit. Now I will have to ask on public-script-coord |
| 22:04 | <jgraham> | I don't like that list :-| |
| 22:04 | <Ms2ger> | -webapps is fine too, and I read that one :) |
| 22:09 | <timeless> | heh |
| 22:10 | <jgraham> | It is? I thought WebIDL was supposed to be discussed on public-script-coord so that the TC39 people could have a chance to get upset at things |
| 22:13 | <Ms2ger> | Exactly |
| 22:15 | <jgraham> | Heh |
| 22:19 | <jgraham> | sicking: I don't know why you said that the element.create / append proposal depends on knowing which strings are tags and which aren't. It doesn't |
| 22:21 | <jgraham> | In particular if we use the form [tagname, attributes, *children] there is no ambiguity |
| 22:21 | <jgraham> | a string at the head of a list is always a tag name. A string not at the head of a list is never a tag name |
| 22:23 | <jgraham> | It is true that appending multiple children to an existing node requires the use of append.apply |
| 22:23 | <jgraham> | If you have an array of templates |
| 22:58 | <smaug____> | I know there is JS error console somewhere in Opera, but I can't find it |
| 22:58 | <smaug____> | ah, there is was.. |
| 22:58 | <smaug____> | hard to find |
| 23:05 | <smaug____> | does anyone know if it is possible to re-enable javascript: in the location bar in Opera? |
| 23:08 | <Hixie> | can one iframe in any way access a sibling iframe if the two iframes and their parent browsing context are in three different origins? |
| 23:11 | <bga_> | smaug____ f12 |
| 23:11 | <Hixie> | to answer my question, per spec, yes. |
| 23:13 | <bga_> | Hixie iirc i can access only to {.frames} and {.name} |
| 23:13 | <Hixie> | window.frames === window |
| 23:13 | <bga_> | its gives me full tree |
| 23:13 | <Hixie> | but you can access window[n] which is what matters |
| 23:13 | <bga_> | hm |
| 23:13 | <bga_> | ok |
| 23:14 | <bga_> | ah. {.length} |
| 23:14 | <bga_> | now i understand :) |
| 23:14 | <smaug____> | bga_: sorry, what does f12 do? |
| 23:15 | <bga_> | smaug____ enable js, flash, proxy etc |
| 23:16 | <smaug____> | bga_: I do have js enabled. I want to enable javascript: in the location bar |
| 23:16 | <smaug____> | currently I get just "Access to this port is disabled for security reasons" |