| 00:16 | <gsnedders> | Hixie: okay, tell me when done then I'll touch html5lib |
| 01:28 | <t3oss> | ambiguous ampersand is called string for writing unicode characters with their unicode codes? |
| 01:28 | <t3oss> | from "< -- "&#x" and ";" is called ambiguous ampersand? |
| 01:35 | <Hixie> | gsnedders: i don't know what the eta on that would be |
| 02:32 | <gsnedders> | Hixie: I'm finally hacking on the stuff I've wanted to work on for ages. Try and learn something over the summer. So, well, not too fussed about html5lib. It mostly works. |
| 08:44 | <Ms2ger> | "We accounted for some tests around algorithms but believe that many algorithm steps, especially intermediate steps, do not require separate tests." |
| 08:45 | <annevk> | URL? |
| 08:45 | <Ms2ger> | http://www.w3.org/mid/E557E34E53296846B3E3EDF9A8640B1923664DCC⊙Ecc |
| 08:55 | Ms2ger | wonders where darobin is nowadays |
| 09:12 | <Ms2ger> | annevk, and happy birthday and stuff |
| 09:12 | <t3oss> | I am making web site about web design, it will have reference to html css javascript php mysql nginx apache etc. Before I put it online I think it will be very nice if someone of the officials here have little time to check it fast, check articles to see if they are 'ok', because I want to give best information to the public without any errors |
| 09:13 | <t3oss> | all the articles are made from html specification |
| 09:37 | <ondras> | question: |
| 09:37 | <ondras> | iframe.contentDocument |
| 09:37 | <SimonSapin> | t3oss: documenting all of this (and maintaining it as new stuff comes up) seems like a lot of duplicated work :( |
| 09:37 | <ondras> | is there any spec stating *when* is this available? |
| 09:38 | <ondras> | e.g. "immediately after setting src" |
| 09:38 | <ondras> | or "after onload" |
| 09:38 | <ondras> | or so? |
| 09:39 | <t3oss> | I think there are some things lacking on the WEB right now and I want to make them but I in order to do so I must have full control so making my own website is only way to go |
| 09:41 | <t3oss> | I believe new web devs will find hard to begin learning directly from HTML spec, even in the spec it says they should read some books or tutorials so there is need to guide them through the spec and describe some intermediate things they might lack that can confuse them |
| 09:49 | <wilhelm> | t3oss: http://www.webplatform.org/ |
| 09:49 | <jgraham> | Argh cross posting |
| 09:49 | <jgraham> | Now I don't know what to do |
| 09:50 | <jgraham> | annevk: also happy birthday if it is indeed your birthday |
| 09:54 | <t3oss> | Does HTML allow text to be written outside of element directly in the body element? |
| 09:57 | <SimonSapin> | t3oss: of course documentation is needed. But it’s a lot of work and thus takes a lot of people. Trying to do it all yourself will just fail. Why do you want full control over this? |
| 09:58 | <t3oss> | also character reference is < and < is code point? |
| 09:58 | <t3oss> | SimonSapin, because I disagree with people most of the time on some things :)) |
| 10:00 | <SimonSapin> | yeah, what could go wrong |
| 10:07 | <t3oss> | also can I write all Unicode characters on the html or just these that are written here? http://www.w3.org/html/wg/drafts/html/master/syntax.html#named-character-references |
| 11:19 | <annevk> | jgornick: ta |
| 11:19 | <annevk> | oops, jgraham / Ms2ger ta |
| 11:19 | <annevk> | didn't realize we had a new jg |
| 11:25 | <annevk> | odinho: haven't really planned visiting Oslo yet |
| 11:25 | <annevk> | odinho: I should soonish I guess |
| 11:36 | <odinho> | annevk: Yeah man <3 |
| 13:22 | <annevk> | transient registered observers, I hate you |
| 13:51 | <annevk> | https://github.com/whatwg/dom/commit/df0f8f510445533697840087262e0724d601eb08 ... |
| 13:54 | <t3oss> | what is going on? http://www.w3.org/html/wg/drafts/html/master/ |
| 13:54 | <t3oss> | I can't open links |
| 13:54 | <annevk> | t3oss: use http://whatwg.org/C |
| 13:57 | <t3oss> | because web dev edition doesn't have info on it |
| 13:57 | <annevk> | you're confused |
| 13:58 | <annevk> | I didn't point you to http://developers.whatwg.org/ |
| 15:33 | <annevk> | Hixie: there's part of a thread in es-discuss addressed to ianh ("Realm, schmealm!"); basically others finding out about what bz has been raising for a bit and bz explaining it (including the bit where it will take other browsers to adopt Gecko's model for the specification to change the security model with regards to multiple globals and different origins) |
| 17:13 | <GPHemsley> | Hixie: Is there an error in the presentation hints for quotes when it comes to en/en-AU/en-GB? Shouldn't some of those be 'test "test" test' ? |
| 17:24 | <TabAtkins> | GPHemsley: Why would they be? (I think you're asserting that the order of double vs single should be reversed?) |
| 17:24 | <GPHemsley> | TabAtkins: It is my understanding that certain varieties of English use the inverted order (double inside single) instead of the listed order. |
| 17:24 | <GPHemsley> | en-US uses single inside double |
| 17:25 | <GPHemsley> | which is not listed |
| 17:25 | <TabAtkins> | Ah, I didn't realize that was even a thing. |
| 17:25 | <TabAtkins> | Arent' dialog conventions the same across them, though? |
| 17:25 | <GPHemsley> | en-AU and en-GB are listed even though they don't differ from en (as written) |
| 17:26 | <GPHemsley> | Amy said, "Bob said, 'I speak English.'" |
| 17:26 | <GPHemsley> | en-US ^ |
| 17:26 | <TabAtkins> | Right. |
| 17:26 | <GPHemsley> | en-GB (I think): Amy said, 'Bob said, "I speak English."' |
| 17:27 | <TabAtkins> | Huh. Well, I don't see that in books I read from Britain, unless they've been converted for an american audience. |
| 17:27 | <zewt> | 「quotes suck」 |
| 17:28 | <jgraham> | GPHemsley: Really? |
| 17:28 | <jgraham> | [citation-needed] on eb-GB |
| 17:28 | <GPHemsley> | "Double quotes are preferred in the United States, and also tend to be preferred in Canada, Australia and New Zealand. Single quotes are more usual in the United Kingdom and South Africa, though double quotes are also common there.[" |
| 17:28 | <GPHemsley> | https://en.wikipedia.org/wiki/Quotation_mark |
| 17:28 | <GPHemsley> | The Penguin Guide to Punctuation, R. L. Trask, p. 94. |
| 17:28 | <GPHemsley> | ;) |
| 17:29 | <jgraham> | Yeah, that doesn't match my experience |
| 17:29 | <jgraham> | Or I have never noticed |
| 17:29 | <zewt> | <- user styles away superscripts on wikipedia (was: re: hard to read) |
| 17:30 | <GPHemsley> | either way, as it stands, the specific rules for en-AU and en-GB are useless, because they duplicate en and there aren't any other en-* styles |
| 17:31 | <GPHemsley> | http://www.whatwg.org/specs/web-apps/current-work/#quotes |
| 17:31 | <GPHemsley> | :root:lang(en), :not(:lang(en)) > :lang(en) { quotes: '\201c' '\201d' '\2018' '\2019' } /* “ ” ‘ ’ */ |
| 17:31 | <GPHemsley> | :root:lang(en-AU), :not(:lang(en-AU)) > :lang(en-AU) { quotes: '\201c' '\201d' '\2018' '\2019' } /* “ ” ‘ ’ */ |
| 17:31 | <GPHemsley> | :root:lang(en-GB), :not(:lang(en-GB)) > :lang(en-GB) { quotes: '\201c' '\201d' '\2018' '\2019' } /* “ ” ‘ ’ */ |
| 17:31 | <jgraham> | "Use double quotes at the start and end of a quoted section, with single quotes for quoted words within that section." - Guardian style guide |
| 17:31 | <TabAtkins> | Right, given their current definition, we can just drop the two specific lines. |
| 17:32 | <jgraham> | http://www.theguardian.com/styleguide/q |
| 17:32 | <GPHemsley> | Yeah, perhaps the inverted order is on its way out |
| 17:33 | <GPHemsley> | someone should check on South Africa |
| 17:33 | <GPHemsley> | (en-ZA) |
| 17:36 | <jgraham> | "quotation marks: use double quotes except in heads, captions or crossheads. Quotes within quotes are single; quotes within quotes within quotes are double" |
| 17:37 | <jgraham> | From The Telegraph |
| 17:38 | <Hixie> | GPHemsley: i autogenerate those parts of the spec from the Unicode CLDR |
| 17:39 | <Hixie> | should be at most a few days behind |
| 17:39 | <GPHemsley> | then perhaps someone should ping the CLDR |
| 17:40 | <jgraham> | And now I wonder why "order of magnitude" is a banned term in The Telegraph |
| 17:53 | <TabAtkins> | Maybe it's unclear what it means? It does have different multiplies in different fields. |
| 17:54 | <TabAtkins> | *2 in comp sci, *10 in physics, often roughly *1000 in common parlance |
| 18:14 | <Hixie> | rafaelw: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22400 |
| 18:55 | <aklein> | Hixie: pong (on behalf of rafaelw), see my last comment |
| 18:55 | <aklein> | Hixie: it logs 1 for me in Chrome and 2 in Firefox |
| 18:56 | <aklein> | (the presence of the <template> has no effect on Chrome's output) |
| 19:34 | <Hixie> | aklein: i see the same as you |
| 19:41 | <aklein> | Hixie: so which spec are you saying chrome doesn't follow? the spec as-is, or the spec with but 22400 fixed? |
| 19:41 | <Hixie> | the spec as is |
| 19:42 | <Hixie> | chrome acts as if the bug was fixed. firefox acts per the spec now. |
| 19:43 | <aklein> | ah, yes: we had to land a fix for this bug to avoid crashes |
| 19:43 | <Hixie> | crashes? |
| 19:43 | <Hixie> | weird |
| 19:43 | <Hixie> | why would this cause crashes? |
| 19:45 | <Hixie> | heycam|away: ok, incumbent stuff is in |
| 19:46 | <aklein> | Hixie: the association between the <form> and the <input> would under some circumstances (in Blink and WebKit, anyway) live longer than the <input> itself, so we'd end up with a use-after-free |
| 19:47 | <Hixie> | interesting |
| 19:47 | <Hixie> | can't you get those same problems without template? |
| 19:47 | <aklein> | I am indeed curious whether the test case you just sent might cause crashes after a GC :) |
| 19:49 | <aklein> | I'm sure it's quite possible to fix those crashes in some other way, but given that they needed to be fixed anyway, it didn't make much semantic sense to us for forms to be associated with elements inside templates |
| 19:49 | <aklein> | if you and the Firefox folks feel differently we'd be open to changing back |
| 19:49 | <aklein> | (and finding another way to fix the crashes) |
| 19:51 | <Hixie> | oh i think the bug is valid |
| 19:51 | <Hixie> | but we should fix the spec, not just the implementation :-P |
| 19:52 | <Hixie> | anyway, if the bug should be fixed, please reassign it to me |
| 19:52 | <Hixie> | right now it's in rafaelw's bucket |
| 19:53 | <aklein> | Hixie: ah, ok, I don't think rafaelw knew you were waiting for him. reassigned |
| 19:54 | <Hixie> | k, thanks |
| 19:55 | <aklein> | Hixie: fyi, your test case crashes chrome |
| 19:55 | <Hixie> | hah |
| 19:56 | <Ms2ger> | aklein, I guess that's better than reading uninitialized memory in IE |
| 19:56 | Ms2ger | did that once |
| 19:58 | <aklein> | Ms2ger: it might be exactly as bad, luckily Chrome has some hardening against trying to wrap deleted memory in JS objects |
| 19:59 | <aklein> | and now I go off to fix Blink |
| 19:59 | <Ms2ger> | Heh |
| 20:06 | Hixie | wonders how exactly to block this |
| 20:07 | <Hixie> | hm, there's a template stack, isn't there |
| 20:08 | <Hixie> | maybe i just don't do the form thing if we're in a template |
| 20:12 | <aklein> | Hixie: for parser-associated form controls like the one in your test case, will it forever be associated with the form? |
| 20:12 | <Hixie> | aklein: until the "reset the form owner" algorithm is run |
| 20:12 | <Hixie> | which could happen whenever or never |
| 20:14 | <aklein> | and in this case, where we never touch the <input> again, it's supposed to stick around forever |
| 20:15 | <aklein> | hmm |
| 20:16 | <aklein> | it seems WebKit and Blink don't follow this very well |
| 20:17 | <jgraham> | Hmm, I wonder if we ever wrote tests for this stuff |
| 20:17 | <jgraham> | I remember going through it with bratell for Presto |
| 20:17 | <Hixie> | aklein: you "just" need a strong reference from the <form> to all its elements, right? |
| 20:19 | <jgraham> | Not with <template>, obviously |
| 20:19 | <jgraham> | (that was a reply to myself) |
| 20:22 | <t3oss> | I am very confused, I have one h1 and more h2 elements and p elements in one section, h2 element has bigger font size then h1 why? |
| 20:29 | <aklein> | Hixie: indeed, but I'm not at all sure that wouldn't create leaks in the Blink implementation. need to go talk to some more folks who know this code better than I. |
| 20:31 | <Ms2ger> | Because h1s look at ancestor sections for their font size and h2 doesn't |
| 20:35 | <t3oss> | why |
| 20:36 | <Hixie> | basically there's two models for headers in the spec |
| 20:36 | <t3oss> | I have this outline <section><h1></h1><h2></h2><p></p><h2></h2><p></p></section> |
| 20:36 | <Hixie> | either you use <h1>-<h6> throughout, or you use <h1> only. |
| 20:36 | <Hixie> | if you mix these (which you're allowed to do), you have to manually style them. |
| 20:37 | <t3oss> | h1 got from any(article,aside,nav,section) h1 { font-size: 1.17em; and h2 from: h2 { display: block; font-size: 1.5em; |
| 20:37 | <t3oss> | Hixie, so you say I must use all h1-h6 headings not just h1 and h2? |
| 20:37 | <Hixie> | well, you have to pick one of these three, basically: |
| 20:38 | <Hixie> | 1. use only <h1>, as in: <section> <h1>...</h1> <section> <h1>...</h1> <p></p> </section> <section> <h1>...</h1> <p></p> </section> </section> |
| 20:39 | <Hixie> | 2. use <h1>-<h6>, as in: <section> <h2>...</h2> <h3>...</h3> <p></p> <h3>...</h3> <p>...</p> </section> (the <h1> would be the page header, not shown here) |
| 20:39 | <Hixie> | 3. do what you're doing now, but manually style all the <h1>-<h6> headers to be as you wish them to be |
| 20:40 | <t3oss> | Hixie I read on the web I should use only 1 h1 element on a web page |
| 20:40 | <Hixie> | that is no longer true with HTML today |
| 20:40 | <t3oss> | aham |
| 20:40 | <Hixie> | it's true if you use model 2 above, but in that case the <h1> would be outside the <Section>, since it would be the title of the <Body>. |
| 20:40 | <t3oss> | ok I think I got it |
| 20:41 | <t3oss> | so valid would be <section><h1></h1><section><h2></h2><p></p></section></section> ? I guess :) |
| 20:41 | <TabAtkins> | Technically valid, but weird. Don't mix your models like that. |
| 20:42 | <TabAtkins> | Either use <section> and just <h1>, or use all the <hn> tags and just let the sections be implicit. |
| 20:42 | <t3oss> | Hixie, in 2nd case h1 must be directly in the body? not nested in any element like section or mine example is valid above? |
| 20:42 | <t3oss> | but where to put the h1 element? directly in the body? why my outline is weird? |
| 20:43 | <Hixie> | <section> is a subsection |
| 20:43 | <Hixie> | so it has a parent section |
| 20:43 | <Hixie> | typically the <body> |
| 20:43 | <Hixie> | that presumably has a heading, right? |
| 20:43 | <Hixie> | so if you're using h1-h6, the h1 would be the heading of that master section, the page, the <body> |
| 20:44 | <t3oss> | ok so h1 I guess goes directly in body not nested if I use it |
| 20:45 | <t3oss> | ok I got it finally thanks Hixie and TabAtkins Ms2ger all thanks a lot |
| 20:45 | <Ms2ger> | Np |
| 20:46 | <t3oss> | one more question and I am off can I use second model Hixie told but avoid using h1 element is that valid? |
| 20:47 | <Ms2ger> | Hixie, did you make it valid? |
| 20:47 | <Hixie> | what? |
| 20:47 | <t3oss> | so <body><sectioon><h2></h2><p></p><h3></h3><p></p><h2></h2><p></p></section></body> |
| 20:47 | <Hixie> | with two <h2>s? |
| 20:48 | <t3oss> | is this valid if I don't use h1 just h2 and h3 |
| 20:48 | <t3oss> | yes Hixie |
| 20:48 | <Hixie> | it's not invalid, i mean, the spec defines that that means, but it's probably not what you want |
| 20:48 | <t3oss> | hm |
| 20:51 | <Hixie> | it would mean the same as: <body><section><h1></h1><p></p><section><h1></h1><p></p></section></section><section><h1></h1><p></p></section></body> |
| 20:51 | <Hixie> | (notice that that's two top-level sections) |
| 20:51 | <Hixie> | (well, subsections of the body) |
| 20:54 | <t3oss> | ok Hixie thanks |
| 20:54 | <t3oss> | for clarifying things that bothered me for some time now |
| 20:55 | <Hixie> | gsnedders: i am no longer aware of open non-editorial parser issues |
| 21:07 | <Hixie> | TabAtkins: ping |
| 21:07 | <TabAtkins> | pong |
| 21:07 | <Hixie> | TabAtkins: you made any progress on a scoped CSS spec? |
| 21:08 | <Hixie> | i've got an e-mail here from you saying you were looking at that earlier this year |
| 21:08 | Hixie | would love to off-load the scoped="" processing model |
| 21:08 | <TabAtkins> | The Cascade and Selectors spec together define how scoped styles work. |
| 21:08 | <Hixie> | does it define @global or whatever replaced that, as well? |
| 21:08 | <TabAtkins> | There's no in-CSS definition of how global-name-defining at-rules work in a scoped context yet, though. |
| 21:09 | <TabAtkins> | No, that's waiting for me to write something. |
| 21:09 | <Hixie> | k |
| 21:09 | <Hixie> | but i can remove the following?: |
| 21:09 | <Hixie> | # For scoped CSS resources, the effect of other @-rules must be scoped to either the scoped sheet and its subresources or to the subtree rooted at the style element's parent (if any), even if the @-rule in question would ordinarily apply to all style sheets that affect the Document, or to all nodes in the Document. Any '@page' rules in scoped CSS resources must be ignored. |
| 21:09 | <Hixie> | (and defer to your spec?) |
| 21:10 | <Hixie> | (mmm, "cascade" is nice to type on a qwerty keyboard) |
| 21:16 | <Hixie> | TabAtkins: what do i have to say to make @import scope properly? |
| 21:17 | <TabAtkins> | Sorry, I'd flipped away. ^^_ |
| 21:17 | <Hixie> | looks like the only hook you provide is for declarations |
| 21:17 | <Hixie> | currently i am replacing the above with: |
| 21:17 | <Hixie> | <p>For the purposes of the CSS Cascade model, any declaration in a <code>style</code> element that |
| 21:17 | <Hixie> | has a <code title="attr-style-scoped">scoped</code> attribute and has a parent node that is an |
| 21:17 | <Hixie> | element is <i>scoped</i>, with the <i>scoping element</i> being the <code>style</code> element's |
| 21:17 | <Hixie> | parent element.</p> |
| 21:17 | <Hixie> | but that doesn't handle @-rules at all, including @import |
| 21:18 | <TabAtkins> | Right, in the absence of the actual Scoping spec, we're just solving the specific things needed for Cascade (scoped declarations interaction with the cascade) and Selectors. |
| 21:19 | <TabAtkins> | Ah, hm. You know, we don't actually define what @import does, at all, in Cascade. |
| 21:20 | <TabAtkins> | Let me define that real quick, so that at least @import will be auto-handled by the fact that the stylesheet is scoped. |
| 21:20 | <Hixie> | hehe |
| 21:25 | GPHemsley | needs to learn how to use a mail client application |
| 21:25 | <Hixie> | yeah, me too |
| 21:25 | <Hixie> | i've screwed up three posts in a row today |
| 21:25 | <Hixie> | to es-discuss |
| 21:30 | <TabAtkins> | Hixie: Okay, the actual effect of @import is now defined, so you don't have to mention anything about @import and scoping. |
| 21:30 | <Hixie> | what do i have to say? |
| 21:30 | <TabAtkins> | But what other at-rules do inside of scoped rules is still not defined, until I write the spec. |
| 21:30 | <TabAtkins> | Nothing. |
| 21:31 | <Hixie> | i mean, what do i say to make the sheet scoped |
| 21:31 | <Hixie> | or do @import rules could as "declarations"? |
| 21:31 | <Hixie> | count |
| 21:31 | <TabAtkins> | Oh, just say the stylesheet becomes scoped. That's a dangling reference, but I'll pick it up later. |
| 21:31 | <Hixie> | ah ok |
| 21:31 | <Hixie> | thanks |
| 21:31 | <TabAtkins> | They don't. at-rules in general aren't defined yet in scoped stylesheets, until I write the spec. |
| 21:32 | <Hixie> | and i define "the style sheet's scoping element"? |
| 21:32 | <TabAtkins> | Yeah. |
| 21:33 | <Hixie> | as in: |
| 21:33 | <Hixie> | <p>For the purposes of the CSS Cascade model, a style sheet declared by a <code>style</code> |
| 21:33 | <Hixie> | element that has a <code title="attr-style-scoped">scoped</code> attribute and has a parent node |
| 21:33 | <Hixie> | that is an element is <i>scoped</i>, with the <i>scoping element</i> being the <code>style</code> |
| 21:33 | <Hixie> | element's parent element.</p> |
| 21:33 | <Hixie> | ...? |
| 21:34 | <TabAtkins> | Yes, that works. |
| 21:34 | <TabAtkins> | You don't need the prelude, I guess (about it being for the purposes of the Cascade model). |
| 21:34 | <TabAtkins> | Since scoping affects more than Cascade. |
| 21:34 | <Hixie> | k |
| 21:34 | <Hixie> | <p>A style sheet declared by a <code>style</code> element that has a <code |
| 21:34 | <Hixie> | title="attr-style-scoped">scoped</code> attribute and has a parent node that is an element is |
| 21:35 | <Hixie> | <i>scoped</i>, with the <i>scoping element</i> being the <code>style</code> element's parent |
| 21:35 | <Hixie> | element. <a href="#refsCSSSCOPED">[CSSSCOPED]</a></p> |
| 21:35 | <Hixie> | with that ref being "XXX" |
| 21:35 | <TabAtkins> | Yeah, golden. |
| 21:36 | <Hixie> | <dt id="refsCSSSCOPED">[CSSSCOPED]</dt> |
| 21:36 | <Hixie> | <dd><cite>CSS Scoped Style Sheets</cite>, T. Atkins. Your Imagination.</dd> |
| 21:43 | <TabAtkins> | Hahaha |
| 21:51 | <odinho> | congrats annevk |
| 21:52 | <jgraham> | The achievement being making it through one more year without dying in some madcap adventure? |
| 21:52 | <odinho> | Yes. Still alive. |
| 23:17 | <jacobolus> | hey guys. sorry, super dodgy wifi and had to move around a bit |
| 23:18 | <jacobolus> | er, whoops |
| 23:18 | <jacobolus> | wrong channel |