| 07:20 | <zcorpan> | TabAtkins: any update on https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/bWgRZOZKmbk ? |
| 07:33 | <zcorpan> | jgraham: https://critic.hoppipolla.co.uk/r/203 this always sets onerror to a function, so i can't use the harness to test for the initial value of onerror (unless i do something ugly like store the value of onerror before i load the harness) |
| 07:34 | <zcorpan> | but i guess that's an ok tradeoff |
| 07:52 | <zcorpan> | TabAtkins: also, any update on <http://www.w3.org/mid/CAAWBYDCTnFbx-VQYF4Oq904p-=5dtpCkvTuZSLPA3DX_cT92Qw⊙mgc>; ? |
| 08:53 | <annevk> | hmm, 60 unread in fora/bug |
| 08:54 | <annevk> | Looks like heycam had a work-related weekend |
| 09:27 | <annevk> | http://www.chromium.org/developers/design-documents/per-page-suborigins |
| 09:28 | <zcorpan> | serializing css declarations is hard |
| 09:29 | <SimonSapin> | zcorpan: how? |
| 09:29 | <zcorpan> | shorthands complicate things |
| 09:33 | <zcorpan> | i might give up trying to write it as an algorithm and instead write a set of constraints |
| 09:38 | <zcorpan> | e.g. how should this be serialized? border:1px solid lime; border-top-width:0; |
| 09:38 | <zcorpan> | or border:1px solid lime; border-top-width:inherit; |
| 09:41 | <annevk> | Do implementations vary all over? |
| 09:42 | <zcorpan> | gecko and webkit vary |
| 09:42 | <zcorpan> | haven't tested ie |
| 09:49 | <SimonSapin> | zcorpan: when serializing a whole rule? Is it not acceptable to just serialize the longhands? |
| 09:51 | <zcorpan> | SimonSapin: yeah. that would be the easiest. but people don't want a gazillion longhands |
| 09:53 | <zcorpan> | knowing when to serialize as a shorthand means special knowledge for each shorthand. e.g. background has specific rules about background-size i think |
| 10:22 | <annevk> | So what you want to have written down somewhere is the internal model border:1px solid lime; border-top-width:0 creates. |
| 10:23 | <annevk> | Then for each set of related properties that has a shared shorthand you'd have some kind of function that outputs whether or not a shorthand can be created for the internal model. |
| 10:23 | <annevk> | That serialization algorithm is ideally defined where the shorthand is defined. |
| 10:34 | <SimonSapin> | annevk: the internal model is a bunch of longhands |
| 10:35 | <zcorpan> | yeah. cssom has the model OK (except it doesn't say what happens for duplicate declarations, but i have that fixed locally) |
| 10:36 | <zcorpan> | even so, border:1px solid lime; border-top-width:0 can be serialized in multiple ways, either border-top/border-right/border-bottom/borderl-left or as border-width/border-style/border-color |
| 10:39 | <annevk> | Yeah, so whoever defines the properties need to decide there. |
| 11:11 | <t3oss> | will webpage function without body and head elements? |
| 11:11 | <t3oss> | I mean, will it be valid? |
| 11:13 | <annevk> | are you talking actual elements or tags? |
| 11:13 | <annevk> | without those elements it won't be valid HTML |
| 11:14 | <annevk> | but you can get those elements without corresponding tags |
| 11:15 | <zcorpan> | t3oss: you can check with http://validator.nu/ |
| 11:16 | <zcorpan> | t3oss: but as annevk says, the elements are there even if you omit the tags (e.g. you can access head/body with script and css) |
| 11:17 | <zcorpan> | t3oss: check with http://software.hixie.ch/utilities/js/live-dom-viewer/ to see the parsed tree |
| 11:18 | <t3oss> | annevk, elements |
| 11:18 | <t3oss> | annevk, but HTML specification says document must have DOCTYPE and HTML root element |
| 11:18 | <t3oss> | so I am confused |
| 11:19 | <t3oss> | aha I see, so if I don't write the elements they will be there like tbody |
| 11:19 | <t3oss> | ok thanks guys annevk zcorpan |
| 11:19 | <annevk> | you write tags |
| 11:19 | <annevk> | you get elements |
| 11:20 | <MikeSmith> | hsivonen: W3C has a GSOC contributor doing some work related to the validator code, and in his changes he's used a couple of Java7isms. One is a minor one -- use of the "diamond operator" syntax, which could easily be changes to just explicitly stating the types -- but another one is use of Strings in switch statements. |
| 11:20 | <t3oss> | annevk, yeah annevk but without tags head and body are there? ok thanks |
| 11:20 | <annevk> | t3oss: yeah, when the parser turns tags into elements it adds a couple if you omitted certain tags |
| 11:20 | <MikeSmith> | hsivonen: it seems to me too early to move to Java7 as a build requirement, but I'd like to know what you think |
| 11:21 | <t3oss> | ok thanks again annevk |
| 11:22 | <MikeSmith> | hsivonen: Among other reasons I think OSX is still just on Java6 |
| 11:24 | <t3oss> | one more thing, charset is required attribute? |
| 11:25 | <annevk> | not sure what the spec says, but it should be |
| 11:25 | <annevk> | MikeSmith: Apple Java is, but isn't Apple removing it completely? |
| 11:30 | <MikeSmith> | annevk: I vaguely remember hearing something about removing it, yeah |
| 11:30 | <MikeSmith> | annevk: but wait I think that's just for applet |
| 11:30 | <MikeSmith> | for browsers, right? |
| 11:31 | <annevk> | I don't know |
| 11:33 | <MikeSmith> | annevk: on another subject, have you get any implementor feedback yet on the changes you made in June to http://notifications.spec.whatwg.org/ ? |
| 11:33 | <annevk> | in July? |
| 11:33 | <t3oss> | annevk, I am not sure why spec says doctype html is enough when validator doesn't validate page without title element in the head |
| 11:34 | <annevk> | t3oss: which spec? |
| 11:34 | <t3oss> | w3c |
| 11:34 | <t3oss> | html5.0 |
| 11:34 | <annevk> | t3oss: pointer? |
| 11:34 | <MikeSmith> | annevk: ah yeah I meant in July |
| 11:35 | <MikeSmith> | t3oss: the spec says the title element is required |
| 11:35 | <MikeSmith> | and it can't be empty |
| 11:35 | <annevk> | MikeSmith: did discuss it, but it's not been implemented yet anywhere |
| 11:35 | <MikeSmith> | annevk: OK |
| 11:35 | <t3oss> | http://www.w3.org/html/wg/drafts/html/master/syntax.html#syntax |
| 11:35 | <annevk> | got another request too for putting some kind of state object in a notification |
| 11:35 | <t3oss> | MikeSmith, no read |
| 11:35 | <annevk> | similar to pushState() |
| 11:35 | <annevk> | haven't really gotten around to that yet |
| 11:36 | <MikeSmith> | annevk: dunno how much you care but the Notifications WG is going to need to move to LC soon, and then to CR before long |
| 11:36 | <annevk> | t3oss: there's both syntax and semantic requirements, you have to read both |
| 11:37 | <annevk> | MikeSmith: dunno how much I care either :) |
| 11:37 | <annevk> | MikeSmith: the whole LC / CR stuff is budged |
| 11:38 | <t3oss> | thanks annevk |
| 11:38 | <MikeSmith> | t3oss: see http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-head-element and http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-title-element |
| 11:39 | <MikeSmith> | annevk: yeah which is why I was just mentioning it as an FYI |
| 11:39 | <t3oss> | MikeSmith, yeag that link says title element is not required but validator won't validate web page without title element |
| 11:39 | <MikeSmith> | t3oss: no it doesn't say that |
| 11:39 | <MikeSmith> | the validator conforms to the spec here |
| 11:40 | <MikeSmith> | if you can't see that you need to read more carefuly |
| 11:40 | <t3oss> | MikeSmith, man spec for head and title says title can be ommited |
| 11:40 | <t3oss> | in some situations.. but in most is required |
| 11:40 | <t3oss> | If it's reasonable for the Document to have no title, then the title element is probably not required. See the head element's content model for a description of when the element is required. |
| 11:41 | <t3oss> | so I guess this goes for emals with html code in them |
| 11:41 | <t3oss> | The title element is a required child in most situations, but when a higher-level protocol provides title information, e.g. in the Subject line of an e-mail when HTML is used as an e-mail authoring format, the title element can be omitted. |
| 11:42 | <t3oss> | MikeSmith, see? |
| 11:42 | <MikeSmith> | t3oss: yeah you've just taught me something |
| 11:42 | <MikeSmith> | I guess you must be feeding e-mail messages to the validator |
| 11:42 | <MikeSmith> | sorry I didn't realize that before now |
| 11:46 | <t3oss> | :D |
| 11:47 | <t3oss> | so this validator is for web page only ? |
| 11:47 | <t3oss> | MikeSmith, cmon don't be rude :) |
| 11:57 | <t3oss> | MikeSmith, sorry if I insulted you in some way |
| 12:00 | <MikeSmith> | t3oss: I'm not insulted and would be glad to try to help you if I understand what problem you're trying to solve |
| 12:01 | <MikeSmith> | if you think the validator shouldn't report a missing title as an error, then file a bug at http://bugzilla.validator.nu/ or https://www.w3.org/Bugs/Public/enter_bug.cgi?product=Validator%20(Nu) or at |
| 12:01 | <t3oss> | MikeSmith, I got confused with validator I guess, I didn't knew validator validates only code for web pages thanks anyway |
| 12:03 | <MikeSmith> | t3oss: if you're pasting content into the textarea part of the validator we have no way of knowing what the context is and the sanest assumption is that you're trying to validate content that you intend to put up on the Web |
| 12:06 | <t3oss> | MikeSmith, when browser parse html file which kind of content it understands? Except elements text and comments is there soemthing else? |
| 12:06 | <t3oss> | and js and css code I forgot that |
| 13:03 | <MikeSmith> | slightlyoff moved? |
| 13:17 | <annevk> | MikeSmith: yeah |
| 13:18 | <MikeSmith> | annevk: was looking forward to seeing him when I visited London |
| 13:18 | <annevk> | you'll have to visit SF instead |
| 13:18 | <MikeSmith> | do now I guess I'll have to visit him wherever he moved to |
| 13:18 | <annevk> | your princess is another castle |
| 13:18 | <MikeSmith> | aha |
| 13:18 | <annevk> | when are you here? |
| 13:19 | <MikeSmith> | dunno but would like to go before the end of the year |
| 13:19 | <MikeSmith> | Nao doesn't mind the cold |
| 13:22 | <darobin> | MikeSmith: don't hesitate to drop by Paris on the way there :) |
| 13:22 | <MikeSmith> | darobin: would love to |
| 13:22 | <MikeSmith> | Nao's never been there either |
| 13:22 | <darobin> | we have a guest room |
| 13:23 | <darobin> | assuming you don't mind overhearing a baby crying in the night and that sort of stuff |
| 13:23 | <MikeSmith> | oh boy, if you're offering we will take you up on that for sure |
| 13:23 | <darobin> | sure thing |
| 13:23 | <MikeSmith> | Nao loves babies |
| 13:23 | <darobin> | just ping me in advance to make sure it's not taken and all |
| 13:23 | <MikeSmith> | I definitely will |
| 13:24 | <darobin> | well if she loves them to the point of getting up to take care of them in the night then you're welcome to actually move in for a while :) |
| 13:25 | <MikeSmith> | hahah :) |
| 13:26 | <annevk> | hah, can't beat that |
| 13:26 | annevk | reads ECMAScript and learns Date() (without new) produces a string. |
| 13:30 | <t3oss> | guys why stepSon is behaving like this? http://jsfiddle.net/pFVn8/1/ |
| 13:30 | <t3oss> | why it is so low? |
| 13:45 | <matjas> | when a CSS module spec refers to “whitespace”, which characters are those exactly? same as http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#space-character? |
| 13:47 | <matjas> | doesn’t seem to be explicitly defined anywhere |
| 13:48 | <zcorpan> | matjas: probably http://www.w3.org/TR/CSS2/syndata.html#whitespace |
| 13:49 | <matjas> | zcorpan: thanks! strange the separate module specs don’t refer to that |
| 13:49 | <matjas> | annevk: try `new Date('1 Octopus 2013')` in Chrome |
| 13:50 | <annevk> | matjas: seems to substr on "Oct" (case-insensitive) |
| 13:51 | <annevk> | e.g. octave does the same |
| 13:51 | <zcorpan> | matjas: which mudule spec(s)? |
| 13:51 | <matjas> | yeah |
| 13:51 | <zewt> | annevk: well, prefix |
| 13:51 | <matjas> | zcorpan: http://www.w3.org/TR/css-fonts-3/ |
| 13:53 | <zcorpan> | matjas: i see "whitespace" and "white space" in that module, both of which are discussing whitespace between tokens in the syntax, which is not normative in that module and is more properly defined in css-syntax now |
| 13:54 | <zcorpan> | matjas: but it could of course include a reference anyway |
| 13:54 | <matjas> | that would definitely be less confusing for n00bs like me :) |
| 13:55 | <zcorpan> | or maybe it's not non-normative, but it would be a layering violation for a module to come up with a different definition of whitespace in the syntax :-) |
| 13:59 | <zcorpan> | matjas: pls file a bug or send email |
| 13:59 | <matjas> | zcorpan: will do |
| 14:00 | <MikeSmith> | annevk: I wonder if when you say that Promises are asyncronous values you should more specifically say they're asyncronous return values |
| 14:01 | <annevk> | MikeSmith: soon we'll have APIs that take them as argument |
| 14:01 | <zcorpan> | (whitespace for the purpose of the white-space property is a different kind of whitespace than css-syntax whitespace) |
| 14:01 | <MikeSmith> | annevk: oh |
| 14:02 | <annevk> | MikeSmith: and in fact, things like Promise.every() take promises as arguments |
| 14:02 | <MikeSmith> | ok |
| 14:11 | <SimonSapin> | zcorpan, matjas: you could say that "whitespace" in that context means "whitespace token" rather than "whitespace character" |
| 14:13 | <zcorpan> | SimonSapin: although it's not so clear in "To avoid mistakes in escaping, it is recommended to quote font family names that contain white space..." since there it's discussing font family name which has nothing to do with css syntax |
| 14:13 | <t3oss> | do you want to see th website I am making? :) |
| 14:14 | <SimonSapin> | zcorpan: oh, yeah. In that case it’s characters |
| 14:14 | <t3oss> | sorry that I am annoying but I make website and I want to put accurate information there, so please eexplain to me shortly do you guys together with w3c peopel make html spec or just you and they take it? |
| 14:14 | <SimonSapin> | but I’d say anything "recommended" is not normative |
| 14:14 | <t3oss> | and change it little and put on the w3c website |
| 14:15 | <zcorpan> | t3oss: sure! (re your website) |
| 14:15 | <zcorpan> | t3oss: see http://wiki.whatwg.org/wiki/FAQ#How_does_the_WHATWG_work.3F |
| 14:18 | <zcorpan> | there's probably a document somewhere discussing what the html wg does but i can't find anything right now |
| 14:18 | zcorpan | summons stevef |
| 14:19 | <t3oss> | zcorpan, I still don't know if w3c peopel are involved in making html or just whatwg then they take it and change it |
| 14:19 | <t3oss> | ok zcorpan thanks for the link its quite big I will read it after shopping thanks man |
| 14:20 | <zcorpan> | t3oss: http://html5doctor.com/interview-steve-faulkner-html5-editor-new-doctor/ might also be interesting |
| 14:21 | <t3oss> | appreciate and please link to me anything you think can be in use of for my website :) it will be quite good I promise that :) people can learn from there a lot and easy, I translate spec to simplify things as much as possible to keep consistency and giving a lot of examples and also guiding people a little :) I have firm and do web dev lessons :) |
| 17:28 | <TabAtkins> | zcorpan: I haven't taken the time to add any of the use-counters I want. ;_; |
| 17:39 | <teoss> | in html I can write any unicode character? |
| 17:56 | <Hixie> | so some months ago, one of the w3c html spec editors asked me for a list of bugs that they could work on, because they didn't want to conflict with changes i was making |
| 17:56 | <Hixie> | which seemed reasonable |
| 17:57 | <Hixie> | so i gave them a list of six bugs i wasn't going to touch for a few months |
| 17:57 | <Hixie> | i've since fixed 3 of the 6. one of the 6 was the <template> thing that robin did do, but then i had to redo. |
| 17:57 | <Hixie> | https://www.w3.org/Bugs/Public/buglist.cgi?status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=exclusion |
| 18:23 | <annevk> | :/ the others don't seem particularly high priority though |
| 18:29 | <tantek> | welcome jgraham to Mozilla! |
| 18:29 | <smaug____> | jgraham: welcome |
| 18:29 | <annevk> | has he been sighted? |
| 18:30 | <smaug____> | apparently in MV |
| 18:31 | <TabAtkins> | jgraham: You've in MV for a bit? |
| 18:31 | <TabAtkins> | s/ve/re/ |
| 18:45 | <ajf> | Hey... This is almost certainly the wrong place to ask, but shouldn't there be an option for <input type=text> elements that wrapping? Something like <input type=text wrap>? A lot of sites use <textarea> for this with JavaScript to prevent newlines, but it seems like the wrong control. |
| 18:46 | felipeduardo | test |
| 18:53 | <annevk> | there's <textarea wrap> |
| 19:01 | <zcorpan> | hsivonen: is livedom.validator.nu kept up-to-date? |
| 19:29 | <zcorpan> | about atob/btoa with typed arrays, is there a reason to support btoa with an arbitrary typed array, instead of saying "i want a typed array" and get a typed array as return value? |
| 19:30 | <zcorpan> | i mean atob |
| 19:36 | <annevk> | We could maybe instead support API-only labels/encodings in the Encoding specification. |
| 19:41 | <Ms2ger> | TabAtkins, Sunnyvale |
| 19:43 | <gsnedders> | Ms2ger: How are you spying on jgraham? |
| 19:43 | <Ms2ger> | I have my ways |
| 19:44 | <gsnedders> | :o |
| 20:09 | <zcorpan> | annevk: could you give an example of how that would be used, in both directions? |
| 20:10 | <annevk> | zcorpan: where will serialization end up? In CSS or CSSOM? |
| 20:11 | <zcorpan> | annevk: i took a mental break and read email instead (just back from vacation) |
| 20:12 | <annevk> | zcorpan: I guess something needs to define which properties belong to a group. And then something needs to define how to serialize that group. |
| 20:12 | <annevk> | zcorpan: That could be in the same place. |
| 20:13 | <zcorpan> | yeah, seems reasonable for the spec defining a shorthand to define how to serialize it |
| 20:13 | <annevk> | zcorpan: then you need to define something with respect to order I suppose |
| 20:14 | <annevk> | zcorpan: in the end it would make the most sense if CSSOM was just a thin layer on top of the internal API |
| 20:14 | <annevk> | zcorpan: or internal model |
| 20:14 | <annevk> | zcorpan: which is not very explicit today in CSS, but could b |
| 20:14 | <annevk> | e |
| 20:15 | <zcorpan> | yeah, i've got the order in which the longhands are stored covered, then i just need to say that they're serialized in that order with the position of shorthands being the same as the first property of that shorthand |
| 20:15 | <zcorpan> | if that makes sense |
| 20:16 | <annevk> | yeah, and you need to account for "nested" longhands somehow (as with border) |
| 20:16 | <zcorpan> | indeed |
| 21:11 | <zcorpan> | "The Timed Text Working Group made several editorial improvements to the specification." |
| 21:14 | <zcorpan> | the changelog actually claims that there is one normative change |
| 21:15 | <Hixie> | over how long a period? |
| 21:16 | <zcorpan> | no wait, i was looking at the wrong place in the changelog |
| 21:18 | <zcorpan> | no, it was right |
| 21:18 | <zcorpan> | https://dvcs.w3.org/hg/ttml/raw-file/default/ttml10/spec/ttml-changes.html#change-history-rec-to-2e-per |
| 21:19 | <zcorpan> | time span being 20101118 to 09 July 2013 |
| 21:22 | <Hixie> | one normative change in 3 years? |
| 21:22 | <Hixie> | that's an amazingly good spec |
| 21:24 | <annevk> | is that how we measure things these days? |
| 21:25 | <Hixie> | :-P |
| 21:28 | <TabAtkins> | zcorpan: Regarding serialization, you planning on defining serialization of the basic types, or do you want Syntax to take care of that? |
| 21:29 | <zcorpan> | TabAtkins: basic types being values? |
| 21:29 | <TabAtkins> | Numbers, strings, etc. |
| 21:29 | <TabAtkins> | For example, which quoting character to use for strings. |
| 21:29 | <TabAtkins> | We're inconsistent in Blink. |
| 21:29 | <zcorpan> | i think that's already covered |
| 21:29 | <TabAtkins> | (And flat-out wrong in some places.) |
| 21:30 | <zcorpan> | what i'm focusing on now is style.cssText and how it should decide on shorthands |
| 21:31 | <Hixie> | abarth: do you know if anything is expected from the html spec as far as CSP and Workers go? |
| 21:41 | <annevk> | TabAtkins: basic types Hixie covered years ago, and it survived |
| 21:41 | <annevk> | implemented, not so much |
| 21:42 | <TabAtkins> | Ah, duh. Sorry. |
| 21:42 | <TabAtkins> | Yeah, our implementation is definitely terrible. |
| 21:43 | <TabAtkins> | Internally, we represent strings and idents identically, with only context to tell them apart. This fails, of course, when a property accepts both, like 'content' (and we have bugs in serializing 'content' because of this). |
| 22:19 | <zcorpan> | another bug in blink http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2429 |
| 22:20 | <TabAtkins> | yaaaay |
| 22:40 | <TabAtkins> | zcorpan: You filing that, or should I? |
| 22:48 | <SimonSapin> | TabAtkins, zcorpan: serialization might exist outside of CSSOM, it makes sense in Syntax IMO |
| 22:49 | <zcorpan> | TabAtkins: please file it, i'm about to go to bed :-) |
| 22:49 | <TabAtkins> | kk! |
| 22:50 | <Hixie> | TabAtkins: how does internal code distinguish them then? |
| 22:50 | <Hixie> | TabAtkins: (strings and idents) |
| 22:51 | <TabAtkins> | Hixie: I think I was wrong - if we're doing things right, it should be distinguishable. |
| 22:54 | <Hixie> | k |
| 22:55 | <Hixie> | i can certainly see it being easy to mix them up |
| 22:55 | <Hixie> | i mean, i do that all the time in my own code in similar situations |
| 22:55 | <Hixie> | token structs/unions that represent "identifier" and "string" in very similar ways |
| 22:58 | <Hixie> | (though i'd imagine in browser code if you're dealing with keywords you'd atomise them) |
| 23:01 | <TabAtkins> | We usually do, but in some cases you have user-defined idents, so we can't. |
| 23:17 | <jgraham> | zcorpan: So I vaugely recall that some browser has a problem with addEventListener("error", function(){}), but maybe I am wrong? |
| 23:17 | <jgraham> | smaug____: Thanks |
| 23:26 | <Hixie> | TabAtkins: ah, right |
| 23:26 | <Hixie> | jgraham: sounds plausible, the spec changed very recently on this |
| 23:26 | <zewt> | surely nothing related to adding a no-op event listener |
| 23:46 | <jgraham> | zewt: The no-op part was misleading |