| 00:05 | <Hixie> | fantastic |
| 00:05 | <Hixie> | for china, gecko uses GB18030, chrome uses GBK, and windows uses windows-936 |
| 00:05 | <Hixie> | note that windows-936 isn't even in encoding.spec.whatwg.org |
| 00:06 | <Hixie> | and wikipedia says of it, "Originally it was identical to GB 2312, and expanded to cover most part of GBK with the release of Windows 95; now superseded by Code page 54936 (GB 18030)." |
| 00:07 | <Hixie> | "GB18030 also maintains compatibility with Windows Codepage 936, sometimes known as GBK, which is Microsoft's extended version of GB2312, with the exception of the euro sign which is given a single byte code of 0x80 in Microsoft's later versions of GBK and a two byte code of A2 E3 in GB18030" |
| 00:07 | <Hixie> | fricking encodings |
| 00:10 | <Hixie> | i love it. gecko, chrome, and Windows all use different names for shift_jis. |
| 00:16 | <Hixie> | only gecko has the locale 'ku' |
| 00:16 | <zewt> | Hixie: "and windows" do you mean IE? |
| 00:16 | <Hixie> | i did a google search for [locale ku] and all that comes up is firefox packages |
| 00:16 | <Hixie> | zewt: i mean vista default code pages - http://msdn.microsoft.com/en-us/goglobal/bb896001 |
| 00:17 | <Hixie> | (ku is kurdish, it seems) |
| 00:43 | GPHemsley | wonders what the context is |
| 01:26 | <GPHemsley> | serialize( type, subtype, parameters ) |
| 01:26 | <GPHemsley> | " The MIME type portion of a parsable MIME type is the result of serializing the type and subtype that result from parsing the parsable MIME type and null parameters. " |
| 01:27 | <GPHemsley> | Does that make sense? It's supposed to mean: serialize( type, subtype, null ) |
| 01:27 | <GPHemsley> | For reference: " A parsed MIME type is the result of parsing a parsable MIME type. A parsed MIME type is made up of a type, a subtype, and a dictionary of parameters. " |
| 01:40 | <GPHemsley> | "A parsable MIME type is a MIME type for which the parse a MIME type algorithm does not return undefined. Every parsable MIME type has a corresponding parsed MIME type, which is the result of parsing the parsable MIME type. A parsed MIME type is made up of a type, a subtype, and a dictionary of parameters. " |
| 01:40 | <GPHemsley> | "The MIME type portion of a parsable MIME type is the result of serializing the type and subtype of its parsed MIME type with null parameters. " |
| 01:44 | <GPHemsley> | tell me github is down again |
| 01:45 | <GPHemsley> | " 1:45 UTC Major service outage. " |
| 01:45 | <GPHemsley> | argh |
| 02:07 | <GPHemsley> | Hixie: If you could bump the wiki server to PHP 5.3.2 or higher (preferably 5.4.x), I could update the wiki to the latest MediaWiki software. (With our current version of PHP, I'm restricted to the 1.19.x line we're currently on.) |
| 02:07 | <Hixie> | let me look |
| 02:08 | <Hixie> | odd, the only options i get are labeled "old, not recommended" |
| 02:09 | <GPHemsley> | hmm |
| 02:10 | <Hixie> | wtf |
| 02:10 | <GPHemsley> | that's very strange |
| 02:11 | <GPHemsley> | well, no rush |
| 02:11 | <GPHemsley> | I just realized recently I hadn't been keeping the wiki software up to date |
| 02:12 | <Hixie> | looks like the machine doesn't have a later php, let me see if i can fix that... |
| 02:13 | <Hixie> | no idea. let me send a support request. |
| 02:14 | <GPHemsley> | k |
| 07:01 | <matjas> | annevk: see logs starting here http://krijnhoetmer.nl/irc-logs/whatwg/20130611#l-936 (if you haven’t already) |
| 07:02 | <matjas> | annevk: also, any news from DreamHost yet (without me CC’ed, perhaps)? |
| 07:02 | <annevk> | matjas: I thought they reactivated the account. The main problem was you compiling Node.js which they don't allow |
| 07:03 | <annevk> | matjas: search for "support⊙dc" in your spam maybe? Email went out June 6 |
| 07:03 | <matjas> | annevk: ah, that explains it. thanks! |
| 07:17 | <annevk> | I should probably read the logs... Been somewhat busy last couple of days. |
| 07:52 | <nessy> | annevk: nice effort in the captions discussion, btw! |
| 08:03 | <jgraham> | Can I be grumpy for a moment, and mention that the presentation of this whole "Extend the Web Forward" thing really distracts from the useful technical discussion? Presenting a point of view as a "manifesto" prominently featuring a list of endorsments comes across as a little self-aggrandising and amounts to a form of argument by authority. Also, asking people to tweet some hashtag suggests an intention to devolve technical discussions to popularity |
| 08:04 | <jgraham> | Note that I'm not complaining about (or commenting on) the technical aspects; only the presentation, which in my eyes leaves good people looking worse than they deserve. |
| 08:06 | <annevk> | nessy: thanks |
| 08:06 | <annevk> | nessy: mostly tried to relay the concerns from rillian et al |
| 08:07 | <annevk> | kinda sounds like it'll be okay either way |
| 08:11 | <annevk> | jgraham: Are you talking about the document itself or the blog posts around it? |
| 08:13 | <jgraham> | annevk: To a certain extent both. Although I'm sure I haven't seen all the blog posts |
| 08:15 | <annevk> | jgraham: having a new set of principles to rally around is kind of a hard concept to communicate |
| 08:15 | <annevk> | jgraham: see e.g. the HTML design principles for what happened last time |
| 08:15 | <annevk> | jgraham: 1JS didn't go smoothly either I believe, but I'm not really familiar with that discussion |
| 08:16 | <jgraham> | The HTML design principles worked extremely well |
| 08:16 | <annevk> | jgraham: yes, but getting the people on board who were not already on board were extremely skeptical of them is what I mean |
| 08:17 | <foolip> | annevk, nessy, which discussion is that? |
| 08:17 | <annevk> | jgraham: there was quite some resistance to "this is how it is" |
| 08:17 | <annevk> | foolip: [redacted] |
| 08:18 | <jgraham> | annevk: I think this approach is even worse for people who don't buy into the philosophy |
| 08:18 | <jgraham> | It's practically self-identifying a clique |
| 08:20 | <hsivonen> | Are there some AC meeting minutes that I get to read somewhere? |
| 08:20 | <annevk> | hsivonen: https://lists.w3.org/Archives/Member/w3c-ac-forum/2013AprJun/0430.html |
| 08:21 | <annevk> | jgraham: you mean with people writing their name at the end of it? |
| 08:21 | <hsivonen> | annevk: thanks |
| 08:25 | <annevk> | jgraham: might be easier to understand your feedback if you got more concrete, either here or in private |
| 08:32 | <jgraham> | annevk: With the list of names, the fact that there wasn't really any public discussion, etc. At least with the HTML design principles we could point to the fact that they were extracted from what we were doing anyway, and were formalised in public. |
| 08:35 | <annevk> | jgraham: so this similarly follows from public activity: web components, navigation controller, and promises |
| 08:35 | <annevk> | jgraham: it was written down as some higher level set of principles to get more people on board |
| 08:35 | <annevk> | jgraham: and as an explanation of what is happening |
| 08:39 | <jgraham> | Right, the specs are public (although suggesting NavigationController has been designed in public is somewhat laughable; a high bandwidth F2F makes sense, but locking it up in a private repo for months afterwards is inexcusable), but there has been no public discussion about whether the high level principles make sense. They have just been presented as a fait accompli. And, to circle back to the original point, that presentation has a strong element |
| 08:58 | <SteveF> | interesting discussion in the AC minutes, ashame its memeber only |
| 08:58 | <hsivonen> | Quite [redacted] that [redacted] is [redacted] in the AC meeting. |
| 08:59 | <Ms2ger> | I'm quite [redacted] that you feel that way |
| 08:59 | <annevk> | [redacted] |
| 08:59 | <Ms2ger> | [DRMd] |
| 09:01 | <annevk> | jgraham: I basically agree with that |
| 09:01 | <annevk> | jgraham: slightlyoff thinks brainstorming in public before the details are done might get you dragged down somehow, but that's certainly not my experience |
| 09:02 | <annevk> | jgraham: I recommend raising this somewhere |
| 09:38 | <hsivonen> | annevk++ for the AC meeting. |
| 10:03 | <nessy> | annevk: nothing new really, but you are right - I don't expect people that want to continue working on WebVTT to join the TTWG because WebVTT there will only be taken though to rec - the real development in my eyes continues in the TTCG |
| 10:06 | <nessy> | foolip: just a discussion of the new proposed charter for the TTWG in the AC meeting - I think it's ok to mention that a discussion took place |
| 10:07 | <annevk> | nessy: btw, you're an AC rep these days? |
| 10:11 | <matjas> | annevk: fyi, dreamhost seems to have unblocked my account now. thanks for the help! |
| 10:12 | <nessy> | annevk: yes, my new employer made me their AC rep - really interesting new role! |
| 10:14 | <darobin> | AC rep is the best thing to do in W3C |
| 10:14 | Ms2ger | read "<annevk> yes, my new employer made me their AC rep - really interesting new role!" |
| 10:14 | <Ms2ger> | That was rather surprising |
| 10:14 | <darobin> | whenever you're pissed off, in a bad mood, or whatever, you can just post a big grumpy rant on ac-forum |
| 10:14 | <darobin> | it's rather liberating |
| 10:14 | <darobin> | even better if drunk |
| 10:15 | <hsivonen> | darobin: with the implication that your rant is backed by some $$$. |
| 10:15 | <Ms2ger> | That's the main difference with Bj�rn / www-archive, I guess |
| 10:15 | <darobin> | hsivonen: better, you're advising, so it has to be constructive |
| 10:16 | <darobin> | you have options, too, it doesn't have to be about the team; it can be about AB reps, who are elected by you and therefore take everything politely :) |
| 10:16 | <nessy> | darobin: I just stand on the sidelines and shake my head on most of those discussions |
| 10:17 | <darobin> | nessy: :) |
| 10:17 | <darobin> | you're too kind |
| 12:33 | <TabAtkins> | zcorpan: Added text to the parser that allows the algos to be invoked directly on strings. |
| 12:34 | <zcorpan> | TabAtkins: thanks |
| 12:34 | <TabAtkins> | For "parse a CSS value", it looks like you've already got a token stream, and are just matching it against the grammar, right? If so, Syntax doesn't need to do anything further. |
| 12:34 | <TabAtkins> | If you want a token stream to match against the grammar, invoke "parse a list of component values" first. |
| 12:35 | <TabAtkins> | Go ahead and put the <an+b> serialization rules in CSSOM, yeah. |
| 12:38 | <zcorpan> | TabAtkins: "parse a CSS value" is invoked with a string |
| 12:39 | <zcorpan> | by http://dev.w3.org/csswg/cssom/#dom-cssstyledeclaration-setproperty |
| 12:40 | <TabAtkins> | Okay, so since grammar productions ultimately simplify to tokens (/component values), you should invoke Syntax there. |
| 12:40 | <zcorpan> | "parse a list of component values"? |
| 12:41 | <TabAtkins> | Yes. |
| 12:41 | <TabAtkins> | Which'll produce a list of tokens + functions and blocks. |
| 13:06 | <zcorpan> | should i say to match the list against the grammar for the property? is that always a boolean result or can a property alter the list? |
| 13:08 | <hsivonen> | does anyone happen to have examples of pages that require BOM to override HTTP in order to work? The pages were broken when I made the Gecko change have migrated away from UTF-16 since then |
| 13:14 | <zcorpan> | TabAtkins: ^ |
| 13:21 | <SimonSapin> | TabAtkins: is "a string" unambiguously Unicode and not bytes? |
| 13:24 | <zcorpan> | from CSSOM's point of view it's DOMString i.e. 16-bit units |
| 13:25 | <zcorpan> | not sure what should happen to lone surrogates |
| 13:25 | <SimonSapin> | uh |
| 13:25 | <zcorpan> | iirc document.write just lets lone surrogates through |
| 13:25 | <SimonSapin> | well, anything non-ASCII is a "name character" for the tokenizer, so it should round-trip |
| 14:24 | <sangwhan> | media.readyState has a note about being able to jump between readyStates discontinously - does that mean a compliant implementation can jump straight from HAVE_NOTHING to HAVE_CURRENT_DATA? |
| 14:25 | <sangwhan> | (While bad, I've seen a corner case where this happens. Just wondering if that can be considered a compliance issue) |
| 14:25 | <hsivonen> | Is there a summary of the <hgroup>/<subhead> bikeshed in a few sentences? |
| 14:25 | <Ms2ger> | "W3C tries to assert dominance" |
| 14:26 | <Ms2ger> | Is one "a few"? |
| 14:26 | <hsivonen> | Ms2ger: W3C or SteveF? |
| 14:27 | <Ms2ger> | Dunno, I look from afar |
| 14:27 | hsivonen | moves to the next thread |
| 14:28 | <SteveF> | hsivonen: bikeshead is good, nothing to do with dominence |
| 14:29 | <SteveF> | hsivonen: trying to work out if people really want/need some way to identify a subheading (that works) |
| 14:30 | <SteveF> | hsivonen: my take is that people should make use of 'custom elements' |
| 14:31 | <hsivonen> | SteveF: custom elements seems like a bad story for something as common for static text |
| 14:31 | <hsivonen> | depends on whether one believes commonly-undestood copyable and pasteable markup has value |
| 14:32 | <SteveF> | hsivonen: i agree, but think they will be used to make all sort crazy semantic stuff |
| 14:32 | <hsivonen> | semantics of custom elements will be an illusion. lots of 386 ahead :-( |
| 14:33 | <SteveF> | semantics of native elements is often an illusion |
| 14:33 | <Ms2ger> | Semantics is an illusion, sheeple |
| 14:33 | <SteveF> | unless they actually do something useful |
| 14:33 | <hsivonen> | SteveF: yeah |
| 14:35 | <SteveF> | hsivonen: if you want to read something about subhead i try to put it into perspective here http://lists.w3.org/Archives/Public/public-html/2013Jun/0025.html |
| 14:37 | hsivonen | notes "semi-mythical outline algorithm" :-) |
| 14:38 | <hsivonen> | SteveF: thanks |
| 14:38 | <SteveF> | np |
| 14:38 | <hsivonen> | I'm unhappy to find more MPEG-2 references in my backlog of HTML WG email. |
| 14:44 | <jgraham> | I'm pretty sure that along the axis of "less valuable to have have known semantics" to "more valuable to have known semantics" headings are on the "more valuable" end |
| 14:45 | <jgraham> | Saying "custom elements" is more or less like saying "just use <font>" |
| 14:47 | <Ms2ger> | People here might be interested in https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/wDV9JHs0mBA as well |
| 14:47 | <darobin> | I agree that custom elements aren't a good way of handling subheaders |
| 14:47 | <darobin> | slightly better than <font> though :) |
| 14:48 | <jgraham> | <font class="subheading"> if you want it to be readable :p |
| 14:48 | <SteveF> | darobin: the custom elements comment was a light hearted one |
| 14:48 | <darobin> | SteveF: it seems to be discussed seriously though :) |
| 14:49 | <jgraham> | Although really people will be writing templates, so more like {{subheading}}foo{{/subheading}} that expands to <font size=24 face="Comic Sans">foo</font> |
| 14:49 | <SteveF> | jgraham: i have been trying to work out how custom elements work, i believe you can extend an element like thus <p is="fancyparagraph></p> which leaves the base semantics (as far as acc API) is concerened, intact |
| 14:50 | <darobin> | SteveF: you don't need web components for a custom element that has no behaviour beyond styling |
| 14:51 | <SteveF> | darobin: right, but people want a way to define stuff like custom semantic elements to make them more real and legit |
| 14:51 | <darobin> | mulling it over a bit, I reckon that <subwhatever> would mostly be useful if it had sane default styling (unless there are e.g. outlining use cases I haven't thought of) |
| 14:52 | <SteveF> | darobin: did you read the email i pointed henry to just before? |
| 14:52 | <jgraham> | SteveF: I might have lost track of custom elements a bit, but last I heard that syntax was only there to placate Hixie and everyone else planned to use something like <x-foo> (I am probably a lot behind though) |
| 14:53 | <jgraham> | They might even have dropped the x- bit |
| 14:53 | <darobin> | SteveF: hmmm, so you thinking about something like https://gist.github.com/anonymous/be98f147a2f885257108 ? |
| 14:54 | <Ms2ger> | I hear they now use <foo-bar> |
| 14:54 | <darobin> | SteveF: yes I read it, I know the UC |
| 14:54 | <SteveF> | jgraham: right, and I have been looking at the examples in polymer, all of which appear to be of the interactive UI with no useful information exposed and no keyboard interaction |
| 14:55 | <darobin> | polymer is a rather impressive undertaking, but the examples could be better |
| 14:55 | <SteveF> | darobin: yes that sort of thing |
| 14:55 | <SteveF> | darobin: now they are only examples, but doesn't auger well |
| 14:56 | <darobin> | SteveF: the thing is, given that to get that you'd have to either inline the <element>...</element> or use <link rel=import href=path/to/element.html> you're going to need to use many subheadings before it becomes more useful than <span role=subheading> |
| 14:57 | <darobin> | I don't think it bodes that bad |
| 14:57 | <SteveF> | darobin also <element name=sub-head extends="p"> is supposed to mean the it uses the pelement thingy in the DOM |
| 14:57 | <darobin> | those are clearly hacker examples, it doesn't necessarily reflect usage |
| 14:57 | <darobin> | right, yes, that would work |
| 14:58 | jgraham | has the opinion that <hgroup> might not be perfect, but it is likely good enough, and certainly not so bad as to be worth the months of anguish |
| 14:59 | <SteveF> | jgraham: no anguish |
| 14:59 | <darobin> | more like some form of vague angst |
| 15:00 | <darobin> | the kind you'd find in a 1920s Austrian experimental film |
| 15:00 | <SteveF> | jgraham: i don't think a formal feature is needed but if it was hgroup would not be my choice... |
| 15:01 | <jgraham> | Well there was a poll of some sort and a WHATWG/W3C fork and multiple(?) extension specs and lots and lots of email that I stopped reading. Which seems quite like anguish to me. |
| 15:11 | <GPHemsley> | hsivonen: See also: https://gist.github.com/jonathantneal/5672276 |
| 15:12 | <GPHemsley> | hsivonen: SteveF's mailing list post doesn't take into account the discussion that JonathanNeal and I had which suggested separate use cases for <hgroup> and <subline>. |
| 15:15 | <GPHemsley> | hsivonen: (Note that I don't necessarily agree with all that JonathanNeal wrote in that document; you might want to check the logs from around that time to see the full discussion.) |
| 15:27 | <hsivonen> | GPHemsley: thanks |
| 16:08 | <SteveF> | jgraham: "Well there was a poll of some sort and a WHATWG/W3C fork and multiple(?) extension specs and lots and lots of email that I stopped reading. Which seems quite like anguish to me." think it was a fair indication that it was a flawed feature |
| 16:09 | <Ms2ger> | subhead? |
| 16:10 | <SteveF> | Ms2ger: thats not a feature its an idea |
| 16:10 | <jgraham> | SteveF: Or an indication that people are apt to get hung up about really unimportant things and overlook significant ones |
| 16:11 | <SteveF> | jgraham: depends on what you think is important |
| 16:15 | <SteveF> | jgraham: there was an intransigence in the W3C wg at that time that is no longer evident, which makes it easier to get stuff done or undone as the case may be |
| 16:35 | <Hixie> | jgraham++ |
| 16:35 | <Hixie> | bummer, missed anne again |
| 16:35 | <Hixie> | i got up at like 7am and i still missed him |
| 16:35 | <Hixie> | what crazy schedule is the man on! |
| 16:36 | <Hixie> | hsivonen: want me to move to Traditional vs Simplified, or should I leave the region names from Vista's list? |
| 16:36 | <Hixie> | hsivonen: (i'm happy to go whichever way you prefer on this) |
| 16:38 | <SimonSapin> | Hixie: I think he’s still in Japan |
| 16:40 | <Hixie> | any idea if he's getting up late or early? |
| 16:40 | <Hixie> | i'll try again this evening i guess |
| 16:41 | <SimonSapin> | we also that that new thing called email ;) |
| 16:41 | <Hixie> | wat |
| 16:41 | <SimonSapin> | s/that that/have that/ |
| 16:44 | <Hixie> | (actually one of the things i want to ask him is why he didn't reply to my e-mail :-P ) |
| 16:44 | <SimonSapin> | oh |
| 16:45 | <Hixie> | GPHemsley: ok so apparently i'm on debian 4 and to move to newer php we have to upgrade to debian 6 |
| 16:45 | <Hixie> | this seems like a win in general |
| 16:45 | <Hixie> | however |
| 16:45 | <Hixie> | however |
| 16:45 | <Hixie> | expect EVERYTHING to break this week |
| 16:45 | <Hixie> | :-) |
| 16:46 | <SimonSapin> | Why stop at Debian 6? 7 is stable |
| 16:47 | <Hixie> | maybe dreamhost haven't got 7 ready yet, who knows |
| 16:52 | <reyre> | Hixie: for the webvtt API is there any validation things that we need to do? like the end time of a cue can't be greater then the start time of the cue? the spec doesn't say anything about that |
| 16:53 | <Hixie> | validation where? |
| 16:54 | <reyre> | Hixie: so when a user sets the endTime, or any of the properties on a WebVTTCue, should there be any validation taking place? |
| 16:55 | <Ms2ger> | What does the spec say? :) |
| 16:55 | <Hixie> | not per the spec, currently |
| 16:56 | <reyre> | Hixie: hmm this my bad.. the WebVTTCue spec seems to be okay with setters.. |
| 16:56 | <Ms2ger> | On another note |
| 16:56 | <Ms2ger> | http://dev.w3.org/html5/webvtt/ is ugly :( |
| 16:56 | <Hixie> | reyre: iirc we intentionally made it possible to set negative-time cues, because otherwise it's hard to set the times on a cue (you have to figure out which of the two you have to set first based on the old values and new values) |
| 16:56 | <Hixie> | reyre: all the other algorithms in the spec should, in theory, handle them gracefully |
| 16:57 | <Hixie> | (endTime is on TextTrackCue, not WebVTTCue, btw) |
| 16:57 | <reyre> | Hixie: yeah, my bad about that. okay thanks for the info |
| 16:57 | <Hixie> | not an problem at all, please do feel free to ask :-) |
| 16:57 | <Hixie> | better safe than sorry :-) |
| 16:58 | <reyre> | Hixie: :) sounds good |
| 16:58 | <Hixie> | and it's not unusual for this kind of question to find errors in the spec :-) |
| 16:59 | <reyre> | Hixie: yeah i've encountered a couple of those already heh |
| 17:30 | <reyre_> | Hixie: so in the WEBVTT data model we have a writing direction, but in the API we have 'vertical' property |
| 17:30 | <reyre_> | how do those two relate? |
| 17:30 | <Hixie> | that's more a question for nessy, she's the editor now. but let me see if i can answer your question, one sec... |
| 17:31 | <Hixie> | reyre_: is the definition of 'vertical' not clear? |
| 17:31 | <Hixie> | reyre_: i'm confused as to the question |
| 17:31 | <Hixie> | what's not clear? |
| 17:32 | <Hixie> | abarth: a webkit bug in the parser is described here https://www.w3.org/Bugs/Public/show_bug.cgi?id=22183 |
| 17:34 | <reyre_> | Hixie: i guess what's not clear is if writing direction and the vertical property are the same thing |
| 17:34 | <reyre_> | which i'm thinking they are |
| 17:34 | <Hixie> | how is that not clear? |
| 17:34 | <Hixie> | (are we looking at the same spec?) |
| 17:34 | <reyre_> | Hixie: http://dev.w3.org/html5/webvtt ? |
| 17:34 | <Hixie> | is http://dev.w3.org/html5/webvtt/#dfn-dom-texttrackcue-vertical what you're reading? |
| 17:34 | <reyre_> | yep |
| 17:34 | <Hixie> | i don't understand how that leaves any room for interpretation |
| 17:35 | <reyre_> | "On setting, the text track cue writing direction" that makes me think there is a property called 'writing direction' instead of the vertical property where it is actually stored |
| 17:35 | <reyre_> | "On setting, the text track cue writing direction must be set to the value given" |
| 17:36 | <Ms2ger> | Could you file a bug to make that an enum too? |
| 17:36 | <Hixie> | reyre_: ?? |
| 17:36 | <reyre_> | Ms2ger: isn't the other bug to make the kind _not_ an enum? (if that's what your referring to) |
| 17:37 | <Hixie> | reyre_: what do you mean by "property"? |
| 17:37 | <reyre_> | Hixie: sorry i mean 'attribute in the webidl' |
| 17:37 | <reyre_> | so the vertical attribute |
| 17:37 | <Hixie> | reyre_: the attributes don't store anything |
| 17:37 | <reyre_> | :/ |
| 17:38 | <Ms2ger> | reyre_, so there's one bug to make HTMLTrackElement.kind not an enum; the other things like that should be, though |
| 17:38 | <Hixie> | there's a "text track cue" thing, which is represented in JS by a "TextTrackCue" object |
| 17:38 | <Hixie> | the "TextTrackCue" object is just an API that exposes, in various ways, the values of the "text track cue" thing |
| 17:38 | <Ms2ger> | reyre_, and you should think about attributes as getter/setter pairs, that helps :) |
| 17:38 | <Hixie> | one of those values is "the text track cue writing direction" |
| 17:39 | <Hixie> | the "vertical" attribute on the TextTrackCue interface has a getter and setter which poke at values of the "text track cue" thing |
| 17:39 | <Hixie> | specifically, the "the text track cue writing direction" value, but that's an implementation detail |
| 17:39 | <Hixie> | as in, it could easily have been multiple values |
| 17:40 | <Hixie> | reyre_: does that make sense? |
| 17:40 | <reyre_> | Hixie: yep, i'm just trying to piece it together with how we do things in Gecko |
| 17:41 | <reyre_> | Ms2ger: i'll file a bug :) |
| 17:41 | <reyre_> | thanks Hixie |
| 17:42 | <Hixie> | np, sorry if i came over as rude :-/ |
| 17:42 | <reyre_> | Hixie: not at all :) |
| 17:42 | <Hixie> | phew |
| 17:53 | <Hixie> | anyone know if you can do a bugzilla search that excludes bugs that have open dependencies? |
| 17:54 | <Hixie> | heycam|away: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22218 |
| 17:55 | <Hixie> | Ms2ger: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22221 ? |
| 17:55 | <Ms2ger> | Yessir? |
| 17:56 | <Hixie> | why is it inconsistent? |
| 17:56 | <Hixie> | i thought you _liked_ enums |
| 17:57 | <Ms2ger> | Yes |
| 17:58 | <Ms2ger> | But not for reflected attributes, I realized |
| 17:58 | <Hixie> | oh is it that it throws an exception instead of ignoring? |
| 17:59 | <Ms2ger> | Ignores instead of transparently setting the content attribute |
| 17:59 | <Hixie> | oh ok |
| 17:59 | <Hixie> | right |
| 18:04 | <Hixie> | i wonder if there's a way to get the behaviour we want while still using enums |
| 18:04 | <Hixie> | i guess not |
| 18:04 | <Hixie> | oh well |
| 18:04 | <Hixie> | no biggie |
| 18:04 | <Ms2ger> | The point of using enums is that your prose doesn't see invalid values, no? :) |
| 18:04 | <Ms2ger> | The point of using enums is that your prose doesn't see invalid values, no? :) |
| 18:05 | <Hixie> | mostly the point is just to be clearer about intent |
| 18:06 | <Ms2ger> | I guess you could say that too |
| 18:15 | <GPHemsley> | Hixie: Good to know. I'm surprised they haven't done things automatically. Did you put in for the upgrade? |
| 18:15 | <Hixie> | yeah |
| 18:16 | <Hixie> | i expect they minimise upgrades to avoid breaking stuff |
| 18:16 | <Hixie> | it does explain why i've been stuck with such an ancient perl, though |
| 18:16 | <GPHemsley> | do we have a lot of scripts on the server? |
| 18:17 | <GPHemsley> | (of any kind) |
| 18:19 | <jgraham> | Debian 4? Isn't that the version that Jesus used? |
| 18:19 | <Hixie> | GPHemsley: yes |
| 18:19 | <Hixie> | the server hosts ~60 domains and subdomains |
| 18:19 | <GPHemsley> | oh |
| 18:19 | <GPHemsley> | this should be fun |
| 18:20 | <Hixie> | including e.g. software.hixie.ch |
| 18:20 | <Hixie> | which has all my games and tools and so on |
| 18:20 | <GPHemsley> | games? |
| 18:20 | <Hixie> | stuff i do in my spare time |
| 18:20 | <GPHemsley> | you have spare time? |
| 18:20 | <Hixie> | some |
| 18:20 | <Hixie> | none of the games are finished... |
| 18:21 | <GPHemsley> | ah |
| 18:21 | <jgraham> | Hixie: I hear there are plenty of specs looking for editors ;) |
| 18:21 | <GPHemsley> | heh |
| 18:21 | <Hixie> | jgraham: if i spend too much time editing, i burn out :-) |
| 18:21 | <Hixie> | jgraham: gotta keep a balance :-) |
| 18:41 | <Hixie> | man it's hard to work out how the url parser can ever fail |
| 18:44 | <Hixie> | in fact i think the answer might be it can't |
| 18:44 | <Hixie> | which is fascinating |
| 18:46 | <Hixie> | i wonder if that's intentional |
| 18:46 | <Hixie> | more questions for anne! |
| 21:41 | <Hixie> | http://test:test/ huh |
| 21:44 | <Hixie> | awesome, spec agrees with firefox |
| 21:44 | <Hixie> | bummer, sicking was useful and gave me more things to test |
| 21:45 | <Hixie> | (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20580) |
| 21:53 | Hixie | writes a test case and finds every browser does the same thing |
| 21:53 | <Hixie> | clearly i wrote my test wrong |
| 22:25 | <Hixie> | so since adding the referer info to the bugs, i'm finding that many of the bogus bugs have no referer field at all. https:->http: maybe? (searches maybe?) |
| 22:25 | <Hixie> | e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=22285 |
| 22:46 | <TabAtkins> | If they have no referrer, it's likely that they... weren't referred. They were direct submissions against the submission url by probing spambots. |
| 22:46 | <TabAtkins> | If they have no referrer, it's likely that they... weren't referred. They were direct submissions against the submission url by probing spambots. |
| 22:49 | <Hixie> | i mean the referrer of the spec, not of the file-bug.cgi script |
| 22:49 | <Hixie> | the referrer of the latter seems to always be one of the specs |
| 22:50 | <Hixie> | (anecdotally, more often the w3.org/TR specs for the crazy bugs, more often the whatwg.org/html multipage spec for the annoyingly insightful and hard to fix bugs) |
| 23:02 | <reyre_> | Hixie: so the WebVTTCue webidl doesn't have [setter throws] on the alignment, vertical, and position attributes, but down lower it says that they are supposed to throw on setting |
| 23:02 | <reyre_> | is that correct? |
| 23:03 | <Hixie> | what is [setter throws] ? |
| 23:04 | <reyre_> | Hixie: i could be wrong about this, but i've seen before in other webidls that when an attribute could throw an error on setting it has a [SetterThrows] above the attribute ? |
| 23:04 | <Hixie> | ah |
| 23:04 | <Hixie> | that's new to me |
| 23:04 | <Hixie> | i don't think i've put that on any of the webidl i've ever written |
| 23:05 | <jsbell> | It's old |
| 23:05 | <jsbell> | A couple years (more?) ago the need to express throwing behavior in WebIDL was removed. |
| 23:05 | <jsbell> | All done in prose now. |
| 23:06 | <reyre_> | hmm okay thanks jsbell |
| 23:06 | <reyre_> | thanks Hixie |
| 23:22 | <rillian> | reyre_: [SetterThrows] survives in the mozilla webidl compiler as an extension to control code generation |
| 23:22 | <rillian> | so it's needed in the implementation's webidl, but not the spec |
| 23:22 | <rillian> | https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings#Throws |
| 23:23 | <rillian> | i.e. we omit the error object reference in the binding call when that decorator is not present |
| 23:23 | <Hixie> | seems like it'd be safer to have [NeverThrows], so the code gets generated in the case where someone didn't think to check |
| 23:24 | <rillian> | I think they'd notice when they implemented the exception, because there'd be no way to throw it. |
| 23:25 | <jsbell> | Blink and Blink have something similar. |
| 23:25 | <rillian> | and concensus was (we wanted that) most things didn't throw |
| 23:25 | GPHemsley | wonders if HTML shouldn't have its own custom icon like the other specs, to differentiate from WHATWG itself. |
| 23:25 | <jsbell> | Er, Blink and WebKIt |
| 23:26 | <reyre_> | rillian: awesome |
| 23:26 | <reyre_> | i think marcus is good to go for that then |
| 23:27 | <rillian> | great |
| 23:27 | <msaad> | yeap |
| 23:30 | <GPHemsley> | Hixie: @WHATWG seems not to have tweeted any changes after r7953 |
| 23:31 | <Hixie> | that's anne's department |
| 23:32 | <GPHemsley> | naturally |