| 00:00 | <zewt> | have you measured the actual impact (memory? cpu time?) that you're worried about in a production implementation, to find out if you're solving a problem that actually exists? |
| 00:00 | <zewt> | because instantiating an object with some unused properties sounds like a long-past problem to me |
| 00:00 | <nessy> | but it can lead to some really wrong rendering - e.g. a metadata cue that was interpreted with WebVTT rendering rules could be displayed as formatted text that is absolute gibberish |
| 00:01 | <nessy> | I'm approaching this from a mental overload / semantic meaning point of view |
| 00:01 | <zewt> | (the last two things you said don't seem related to me) |
| 00:02 | <nessy> | if I am to author JSON cues and wanted them rendered, I'd want them rendered as plain text |
| 00:03 | <zewt> | err, json cues would be metadata, therefore not rendered? |
| 00:03 | <nessy> | read up - Hixie says all cues need to be regarded as potentially rendered |
| 00:03 | <zewt> | (sorry, coming in late to this and may have missed some bits) |
| 00:04 | <zewt> | guessing "you might render a metadata cue onscreen" isn't what he meant, but I'll punt until he gets back and can speak for himself |
| 00:04 | <nessy> | the not-rendering of some cues is the whole point of this discussion |
| 00:04 | <nessy> | Hixie's point is that a kind=metadata track can be converted into a kind=subtitles track at any time and would then need to be rendered |
| 00:05 | <nessy> | therefore, all tracks have an associated rendering rule |
| 00:06 | <zewt> | don't have anything to add beyond restating that I don't think the expectation is that metadata cues should make any sense when rendered onscreen (though certainly the result should be well-defined) |
| 00:06 | <nessy> | I guess what I want is that tracks should never be able to change their @kind - and therefore there are tracks that are never rendered and never meant to be rendered |
| 00:07 | <nessy> | brb |
| 00:07 | <zewt> | unless a script for some reason forces a track from one kind to another I don't know why that would happen |
| 00:08 | <zewt> | from what I understand (and it's been a while), the point of metadata tracks is to have non-caption-like data available to scripts, which is never rendered automatically |
| 00:09 | <zewt> | afk |
| 00:13 | <TabAtkins> | heycam: Yo, any ETA on the MapLike feature? |
| 00:13 | <TabAtkins> | Got specs we wanna use it in, like, yesterday. ^_^ |
| 00:14 | <TabAtkins> | (And I keep recommending more do so - just wrote feedback on WebMIDI that they should use a MapLike.) |
| 00:14 | <heycam> | TabAtkins, you can just start using it before I add it, that's what Hixie usually does ;) |
| 00:14 | <heycam> | TabAtkins, but next week, probably |
| 00:14 | <TabAtkins> | Yeah, but I dunno what syntax you'll want for it! Sketch it for me, and I'll go ahead. |
| 00:15 | <heycam> | TabAtkins, ok I guess it probably needs a bit of thought; it's not just like [ArrayLike]. |
| 00:17 | heycam | will need to get to it next week, so hold tight. :) |
| 00:17 | <TabAtkins> | Actually, it's probably pretty similar. Declaring an interface to be [MapLike] just means you need to define the list of key/value tuples (which automatically defines an @@iterator method), and if it's writeable, a set and delete method. You *should* define a get() method. |
| 00:18 | <TabAtkins> | But anyway, I'm okay with waiting a week. ^_^ |
| 00:18 | <heycam> | cool |
| 00:19 | <TabAtkins> | It would be cool if we got assigning behavior for free; that is, if an attribute is defined to be a MapLike type, and is writeable, then assigning a Map-like to it (anything with Map on the prototype) does a .clear() on the existing map, then adds all the new key/values to it. |
| 00:34 | <Hixie> | (back, but laggy) |
| 00:34 | <Hixie> | nessy: a track wouldn't change from metadata to subtitles unless you specifically told it to |
| 00:34 | <Hixie> | nessy: just like you could convert a "DontRenderCue" to a "WebVTTCue" |
| 00:34 | <Hixie> | if we added a DontRenderCue |
| 00:34 | <Hixie> | so that doesn't seem like a compelling argument |
| 00:35 | <Hixie> | (though i'm confused about why your reason for wanting this has changed over time... you went from "it's heavy" to "it might be rendered", e.g.) |
| 00:35 | <reyre_> | what's the use case for adding JSON data to some kind of trakc? |
| 00:35 | <Hixie> | reyre_: well you might want time-aligned data, and WebVTT provides a convenient way to do that |
| 00:35 | <Hixie> | reyre_: e.g. for timing when to load up advertising |
| 00:36 | <reyre_> | Hixie: why use JSON in that case tho? WEBVTT will provide. i'm confused on how this JSON would be meant to be added. as the cue text? as metadata? or something else .. ? |
| 00:37 | <reyre_> | or jsut the ability to add JSON in general? |
| 00:37 | <TabAtkins> | reyre_: As a metadata track. You'll get notified with the track value when the cue gets activated, so you can act on it. |
| 00:37 | <Hixie> | reyre_: you don't have to use json |
| 00:37 | <Hixie> | reyre_: you can use whatever you want |
| 00:37 | <Hixie> | reyre_: it's just text |
| 00:37 | <Hixie> | could use xml, your own format, whatever |
| 00:39 | <reyre_> | so nessy wants to add JSON to webvt text, without rendering, so that you can do whatever you want with it via JS when the cue is detected as active? |
| 00:40 | <Hixie> | you can already do all this |
| 00:40 | <reyre_> | yea |
| 00:40 | <Hixie> | what nessy wants is to invent a new format separate from WebVTT that does the same thing (and doesn't have a serialisation) |
| 00:41 | <reyre_> | alright, i understand now, heh, thank you |
| 00:41 | <Hixie> | glad you do, i still don't :-) |
| 00:42 | <reyre_> | well i understand the crux of the conversation ;) now, not why we need another track spec |
| 00:57 | <TabAtkins> | heycam: I've gone ahead and used some pretend syntax for [MapClass] in http://dev.w3.org/csswg/css-variables/#the-CSSVariablesMap-interface |
| 00:58 | <heycam> | TabAtkins, great! |
| 00:58 | heycam | notes it down |
| 00:59 | <TabAtkins> | heycam: The [MapClass()] attribute takes two arguments, which define the key and value types of the map tuples. The spec author has to define set() and delete() methods if the interface is writeable. The spec author *may* define get() and has() methods (I have to, in this case, because I have to do some argument mangling); otherwise, the argument is looked |
| 00:59 | <TabAtkins> | up in the map tuples and returned directly. You get size() for free from the definition of the map tuples, and the rest of the Map methods are free from https://gist.github.com/jorendorff/5662673 |
| 01:00 | <TabAtkins> | Oh yeah, the spec author has to define the map tuples, similar to defining the list of named properties on a getter/setter interface. |
| 01:00 | <TabAtkins> | The attribute, like [ArrayClass], puts Map as the interface's prototype. |
| 01:00 | <heycam> | TabAtkins, so actual Map.prototype? |
| 01:00 | <TabAtkins> | Yeah. |
| 01:01 | <heycam> | TabAtkins, I thought we had come to the conclusion that just having same named similar behaviour methods on the object is preferable |
| 01:01 | <TabAtkins> | So that "obj instanceof Map" works. |
| 01:01 | <TabAtkins> | heycam: Still need a reliable ducktype. |
| 01:01 | <TabAtkins> | The Map.prototype objects don't actually work on the object. |
| 01:01 | <heycam> | so how do you solve the problem that Map.prototype.blah can get around the restrictions that your specific map type wants to enforce? |
| 01:01 | <TabAtkins> | It's just used for typing. |
| 01:01 | <heycam> | oh |
| 01:01 | <heycam> | I see |
| 01:01 | <TabAtkins> | They can't, because [[MapData]] doesn't exist on the object. ^_^ |
| 01:01 | <heycam> | and all its methods are shadowed? |
| 01:01 | <heycam> | right |
| 01:01 | <TabAtkins> | Yeah. |
| 01:02 | <TabAtkins> | [SetClass(valType)] works similarly. |
| 01:03 | <heycam> | ok |
| 01:03 | <heycam> | I am not sure that inheriting from Map.prototype is worth it |
| 01:04 | <TabAtkins> | It works with [ArrayClass], why not here? |
| 01:05 | <nessy> | reyre_, Hixie: I don't want to invent a new format separate from WebVTT |
| 01:05 | <heycam> | TabAtkins, most of the Array.prototype methods are generic, and don't require the object to be an actual array instance |
| 01:05 | <TabAtkins> | (I'm also not sure why [ArrayClass] prevents the interface from being extended. That doesn't seem like a necessary restriction for [MapClass].) |
| 01:06 | <TabAtkins> | heycam: Yeah, it's a failure of Map/Set that that's not true of them. Frustrating that tc39 doesn't see that. |
| 01:06 | <nessy> | reyre_, Hixie: I want to have an object that conveys that it is not being rendered |
| 01:06 | <TabAtkins> | I mean, if they just defined the additional methods on top of the core 5 (@@iterator, get, set, has, delete), it would work easily. |
| 01:06 | <heycam> | TabAtkins, because how do you set MyArrayClassInterface.prototype to both Array.prototype and the interface prototype object of the interface you would inherit from? |
| 01:06 | <nessy> | reyre_, Hixie: as I said - WebVTT, TTML and all other caption formats are already serialisations for non-rendered timed text cues |
| 01:07 | <TabAtkins> | heycam: Oh, is *that* what you're saying? It sounds like it's saying you can't have "MyArraylikeSubclass extends MyArraylikeClass {...}". |
| 01:07 | <TabAtkins> | Which sounded silly. |
| 01:08 | <heycam> | TabAtkins, yeah, the other way around |
| 01:08 | <heycam> | TabAtkins, please file a bug if it's unclear :) |
| 01:08 | <TabAtkins> | Ah, I was misreading. I actually followed the link now. |
| 01:08 | <nessy> | reyre_, Hixie: a cue that is not making use of any of the rendering functionality that is associated with a serialised timed text format should not have to be classified as being a representations of one such format |
| 01:08 | <TabAtkins> | It's quite clear if you click on "inherited interfaces". |
| 01:09 | <nessy> | reyre_, Hixie: in particular if that cue is authored in JS only |
| 01:10 | <heycam> | cool |
| 01:10 | <heycam> | so yeah I'll think and respond to your use of [MapClass] some time next week. thanks for the prodding. :) |
| 01:11 | <TabAtkins> | Cool. I'm poking the thread right now with everything I've said here. |
| 01:11 | <Hixie> | nessy: if you have a WebVTT file, you're getting WebVTTCue objects out of it |
| 01:11 | <nessy> | Hixie: if you're authoring in JS, you don't have a WebVTT file |
| 01:12 | <Hixie> | nessy: i really don't understand what you're arguing |
| 01:13 | <Hixie> | nessy: if "WebVTT, TTML and all other caption formats are already serialisations for non-rendered timed text cues", then how can those cues not use WebVTTCue or TTMLCue or whatever? |
| 01:13 | <nessy> | Hixie: I create a new track using addTextTrack("metadata") |
| 01:13 | <nessy> | Hixie: then I want to add cues to that - why would they need to be WebVTTCue objects? |
| 01:13 | <Hixie> | nessy: they can be whatever format you want (that the browser supports) |
| 01:13 | <Hixie> | nessy: why would they _not_ be WebVTTCue objects? |
| 01:14 | <nessy> | Hixie: because I don't care about the WebVTT functionality |
| 01:14 | <nessy> | Hixie: or the TTML or whatever |
| 01:16 | <Hixie> | nessy: do you think that we should have a subset of Element that doesn't have the namespaceURI attribute, for people who don't care about namespaces? |
| 01:17 | <nessy> | Hixie: no, obviously not - but why then are we distinguishing between WebVTTCue and TextTrackCue if everything is the same anyway? |
| 01:17 | <Hixie> | nessy: WebVTTCue is like HTMLBodyElement, TextTrackCue is like HTMLElement |
| 01:17 | <Hixie> | or actually, WebVTTCue is like HTMLElement, and TextTrackCue is like Element |
| 01:18 | <Hixie> | actually even that's not quite right |
| 01:18 | <Hixie> | it's more like WebVTTCue is like Element, and TextTrackCue is like Node |
| 01:18 | <Hixie> | nessy: it's specifically because everything is _not_ the same |
| 01:18 | <Hixie> | nessy: some cues have text, some cues are images |
| 01:19 | <nessy> | Hixie: can cues with images end up being TextTrackCue objects? |
| 01:20 | <Hixie> | nessy: e.g. if a browser supports DVD's format, and exposes the bitmap image cues |
| 01:21 | <Hixie> | i should say, some text tracks have cues that have text, other text tracks have cues that are images |
| 01:21 | <Hixie> | within a single text track, all cues are the same type |
| 01:21 | <nessy> | Hixie: a browser would require to create a new DVDImageCue object with a specific rendering algorithm to support bitmap image cues, right? |
| 01:22 | <nessy> | Hixie: if we can only have cues that have a rendering algorithm associated, TextTrackCue is never used, because it doesn't have a rendering algorithm, right? |
| 01:23 | <Hixie> | nessy: TextTrackCue is an abstract interface that is inherited from by all the concrete cue types |
| 01:23 | <Hixie> | just like Node |
| 01:23 | <Hixie> | you never construct an actual Node |
| 01:24 | <nessy> | the browser internally constructs nodes and handles them - but TextTrackCue - when would it construct and handle such an object? |
| 01:25 | <Hixie> | the browser never constructs and handles an instance of Node |
| 01:25 | <Hixie> | just like a browser never constructs or handles an instance of TextTrackCue |
| 01:26 | <Hixie> | browsers always deal with objects that implement interfaces that inherit from Node or TextTrackCue |
| 01:29 | <nessy> | Hixie: ok, let me see if I follow |
| 01:36 | <nessy> | Hixie: when in JS and I construct a track with addTrack("metadata") assuming I am in a browser, which supports WebVTTCue, TTMLCue and DVDBitmapCue , then it doesn't matter if I use WebVTTCue or TTMLCue to create e.g. JSON cues ? |
| 01:37 | <nessy> | Hixie: even if that means that when I try to debug the JSON and thus turn the track from kind="metadata" to kind="subtitles" will be rendered funnily either the WebVTT way or the TTML way? |
| 01:37 | <Hixie> | well, it matters depending on what you want from it. for example, if you want to compatible with another browser that only does WebVTTCue, then you should probably use that. |
| 01:37 | <nessy> | (s/JSON/custom XML/ if you prefer) |
| 01:37 | <Hixie> | but beyond that, it doesn't matter, indeed |
| 01:38 | <Hixie> | (dinner bbiab) |
| 02:34 | <nessy> | Hixie: a bit of a follow-on: what's the difference between the two rendering algorithms in WebVTT http://dev.w3.org/html5/webvtt/#rendering ? |
| 02:36 | <nessy> | Hixie: is the first one about how we render cues when they are not overlayed on a video? or is that for how to render webvtt chapters? |
| 02:36 | <nessy> | Hixie: I'm just not clear if they are two different rendering algorithms to be used with <track> or what problem the first one is supposed to solve... |
| 03:11 | <Hixie> | nessy: first one is for when e.g. you are rendering a chapter title in the UI |
| 03:12 | <Hixie> | nessy: the other one is for when you are rendering cues over video |
| 03:14 | <nessy> | Hixie: what were your intentions for how to render chapter title in the UI - was that basically a hierarchical list in a drop-down box? Did we want to prescribe this? |
| 03:14 | <Hixie> | i don't expect it'd be anything clever |
| 03:14 | <Hixie> | just has to be defined |
| 03:14 | <Hixie> | so that UAs do the same thing |
| 03:44 | <nessy> | Hixie: so that rendering algorithm comes into effect when kind=chapters while the other one when kind={captions,subtitles} - correct? |
| 03:47 | <Hixie> | not necessarily, but usually, sure |
| 03:48 | <nessy> | Hixie: would a TTMLCue that renders chapters need to provide its pwn rendering rules, too? |
| 03:48 | <nessy> | s/pwn/own/ |
| 03:51 | <Hixie> | yup |
| 03:56 | <nessy> | Hixie: isn't that a bit of a waste - every text-based track format re-defining it, and could potentially lead to different chapter UIs based on which format you use? |
| 04:04 | <Hixie> | ? |
| 04:04 | <Hixie> | we need to define how it works... |
| 04:04 | <Hixie> | how else could you do it? |
| 04:05 | <Hixie> | that's like saying "isn't it a waste that html and svg both have to define their DOM APIs" or something... |
| 04:08 | <nessy> | well, if there was a ChapterCue and it had the rendering algorithm in HTML, and tracks with kind=chapters would cause only ChapterCues to be created from a TTML or WebVTT file, then neither would need to define it |
| 04:09 | <Hixie> | o_O |
| 04:09 | <nessy> | then it would be well defined how chapters in HTML are rendered, but other platforms could render them in other ways |
| 04:10 | <Hixie> | i don't understand what you are proposing at all |
| 04:10 | <Hixie> | how do you know what cue is a chapter cue? |
| 04:10 | <Hixie> | how do you convert from TTML to this chapter cue format? |
| 04:11 | <nessy> | it's plain text, there is no conversion |
| 04:11 | <Hixie> | ??? |
| 04:11 | <Hixie> | TTML is XML, not plain text... |
| 04:12 | <nessy> | right, I mean: after the cues are extracted |
| 04:12 | <nessy> | a chapter in WebVTT is a cue with some plain text that is the chapter title, right? |
| 04:13 | <nessy> | that plain text needs no conversion - it's just a parsed out cue |
| 04:13 | <Hixie> | that's what this algorithm would be about defining |
| 04:18 | <nessy> | what I'm grappling with is: for chapters, metadata, plain descriptions and even plain subtitles, all we need is cues with plain text |
| 04:18 | <nessy> | and this is universal, no matter how they get into the browser |
| 04:18 | <nessy> | trying to make them look like they are WebVTTCue or TTMLCue or something else that they are not, is very confusing |
| 04:19 | <nessy> | to a JS dev |
| 08:45 | <zcorpan> | TabAtkins: how should i invoke "parse a rule"? the input is a stream of tokens or component values but i have a string |
| 08:55 | <SimonSapin> | zcorpan_: the tokenizer does that … but we should have Syntax define that its used when the input is a string, so you don’t have to. |
| 08:55 | <zcorpan_> | yeah |
| 08:55 | <zcorpan_> | i'll just invoke it with a string for now |
| 08:56 | <SimonSapin> | should be fine |
| 11:29 | <zcorpan> | i don't know if i should change http://dev.w3.org/csswg/cssom/#parse-a-css-value to say something in terms of css-syntax or not |
| 11:29 | <zcorpan> | TabAtkins: SimonSapin: ^ |
| 11:36 | <hsivonen> | So fun when a bunch of tests fail when adding an extra event loop spin where the spec requires one |
| 11:37 | <jgraham> | hsivonen: What did you break^Wfix this time? |
| 11:42 | <hsivonen> | jgraham: <script defer> still |
| 11:42 | <hsivonen> | but even without any deferred scripts, adding an event loop spin between the readystatechange to interactive and DOMContentLoaded seems to break a bunch of tests for no obvious reason |
| 12:00 | <darobin> | zcorpan: do you have a bit more information to provide on https://www.w3.org/Bugs/Public/show_bug.cgi?id=21912 ? It's a tad terse |
| 12:02 | <zcorpan> | darobin: commented |
| 12:02 | <darobin> | thanks |
| 12:03 | <darobin> | oh, that, yes |
| 12:09 | <zcorpan> | TabAtkins: should i put Serializing <an+b> in cssom? |
| 14:11 | <zcorpan_> | annevk: how do i abort a fetch? |
| 15:48 | <GPHemsley> | annevk: ICYMI: "parse a MIME type" is now defined in mimesniff, so you can update Fetch's definition of a "simple header" |
| 15:49 | <GPHemsley> | annevk: Oh, I should have read further. I guess we'll have to discuss. |
| 15:50 | <Hixie> | heh |
| 15:54 | <GPHemsley> | What is the opposite of "parse"? "construct"? "assemble"? |
| 15:54 | <Hixie> | serialise |
| 15:54 | <GPHemsley> | en-US, please :P |
| 15:54 | <Hixie> | adapt as desired :-) |
| 15:55 | <GPHemsley> | so what's the difference between "parse" and "deserialize"? |
| 15:55 | <Hixie> | nothing |
| 15:55 | <GPHemsley> | ah |
| 15:55 | <Hixie> | well |
| 15:55 | <GPHemsley> | I was gonna suggest that "parse" is a jump-in point for a (de)serialize loop |
| 15:56 | <Hixie> | "deserialize" tends to imply that the data is expected to have been generated by the same, or closely related, code |
| 15:56 | <Hixie> | whereas "parse" tends to imply, if anything, that the data was generated by a human, or some unrelated, less trusted code |
| 15:56 | <GPHemsley> | ah, so I was pretty close, then |
| 15:57 | <GPHemsley> | effectively, (de)serialize would follow an ABNF, while "parse" likely wouldn't |
| 15:57 | <Hixie> | no, it's more about where the data came from |
| 15:57 | <Hixie> | e.g. you parse HTML or JSON, but you deserialise a save file in a game |
| 15:58 | <GPHemsley> | hmm |
| 15:58 | <Hixie> | but really they mean the same thing, that distinction is a bit rarefied imho |
| 15:58 | <GPHemsley> | effectively, (de)serialize would follow an ABNF, while "parse" likely wouldn't |
| 15:58 | <Hixie> | no, it's more about where the data came from |
| 15:58 | <Hixie> | e.g. you parse HTML or JSON, but you deserialise a save file in a game |
| 15:58 | <GPHemsley> | hmm |
| 15:58 | <Hixie> | but really they mean the same thing, that distinction is a bit rarefied imho |
| 15:58 | <GPHemsley> | presumably deserialize is a subset of parse |
| 15:58 | <GPHemsley> | in terms of accepted input |
| 15:59 | <Hixie> | i would recommend always using "parse" :-) |
| 15:59 | <GPHemsley> | naturally :) |
| 15:59 | <jgraham> | JSON.parse(JSON.serialize(some_object)) <- deserialize; JSON.parse('[{some:"human"}, "input"]' <- parse |
| 15:59 | <jgraham> | In hixie's vernacular |
| 15:59 | <GPHemsley> | right |
| 15:59 | <Hixie> | yeah, something like that |
| 15:59 | <Ms2ger> | ) |
| 15:59 | <GPHemsley> | :) |
| 15:59 | <Hixie> | oh no, now we have two! |
| 16:00 | <jgraham> | In my opinion, deserialize is a silly word :) |
| 16:00 | <Hixie> | yeah, mine too |
| 16:00 | <jgraham> | Almost as bad as uneval |
| 16:00 | <GPHemsley> | for my purposes, "parse" is my (the WHATWG's) job, "deserialize" is the IETF's job |
| 16:00 | <jgraham> | (I kind of expect uneval(4) === 2+2) |
| 16:01 | <Hixie> | uneval(sendEmail()) => e-mail is no longer sent? :-) |
| 16:01 | GPHemsley | walks away from the edge of the rabbit hole |
| 16:06 | Ms2ger | pushes GPHemsley back in |
| 16:08 | <jgraham> | GPHemsley: I recommend avoiding the honey |
| 16:41 | <Ms2ger> | "Reopening the casing issue" |
| 16:41 | <Hixie> | which one is that? |
| 16:41 | <Ms2ger> | Yeah, like I didn't get enough email |
| 16:41 | <Ms2ger> | css-variables |
| 16:41 | <Hixie> | oh dear |
| 17:08 | gsnedders | wonders whether it's worth fighting to get more trees the parser can create to have obvious serializations |
| 17:14 | <Ms2ger> | "Steven Pemberton, Chair of the Forms Working Group, gives a talk..." |
| 17:14 | <Ms2ger> | Want to guess a date? |
| 18:09 | <GPHemsley> | <3 "Are you sure you want to reload this page?" |
| 18:15 | <GPHemsley> | which is better? "the U+XXXX FOOBAR character" or "the character U+XXX FOOBAR"? |
| 18:15 | <GPHemsley> | which is better? "the U+XXXX FOOBAR character" or "the character U+XXX FOOBAR"? |
| 18:15 | <GPHemsley> | does context matter? |
| 18:19 | <Hixie> | i prefer the U+0073 LATIN SMALL LETTER S character |
| 18:19 | <Hixie> | and to make it easy to be consistent, that's the format that http://software.hixie.ch/utilities/cgi/unicode-decoder/character-identifier?characters=s outputs |
| 18:19 | <Hixie> | (that script is broken for non-ascii characters) |
| 18:20 | <jsbell> | hee hee |
| 18:20 | <Hixie> | (and for punctuation, i prefer this, also used by that script: U+002E FULL STOP character (.) ) |
| 18:24 | <GPHemsley> | ah, very nice |
| 18:33 | <GPHemsley> | Feedback welcome: http://mimesniff.spec.whatwg.org/#serialize-a-mime-type |
| 18:36 | <matjas> | Hixie, GPHemsley: zcorpan made a similar tool that is useful when writing specs: http://simon.html5.org/tools/js/unicodeize/ |
| 19:45 | <Hixie> | matjas: nice |
| 19:45 | <matjas> | annevk (if you’re reading the logs): for https://github.com/annevk/url, e.g. if you ever need to turn http://url.spec.whatwg.org/#url-code-points into a JavaScript-compatible regular expression, you may want to use http://mths.be/regenerate |
| 19:47 | <GPHemsley> | matjas, zcorpan: Do you know what format that's using? (Could it be changed to the one Hixie and I discussed earlier?) |
| 19:47 | <GPHemsley> | or add some toggles or something |
| 19:47 | <matjas> | GPHemsley: example output is used here http://javascript.spec.whatwg.org/#escapeattributevalue |
| 19:47 | <Hixie> | it's just a string in quotes followed by the same characters as unicode codepoints without names, in parenthesese |
| 19:48 | <matjas> | GPHemsley: IIRC zcorpan uses the same format in his specs too |
| 19:48 | <GPHemsley> | ah, hmm |
| 19:48 | <Hixie> | so it's more for strings than characters |
| 19:48 | <Hixie> | i use a similar format sometimes |
| 19:48 | <GPHemsley> | yeah, I suppose |
| 19:48 | <Hixie> | though i tend to give the character names as well |
| 19:48 | <Hixie> | e.g.: the string "</" (U+003C LESS-THAN SIGN, U+002F SOLIDUS) |
| 19:49 | <GPHemsley> | actually, 'Let escaped be value with each U+0022 QUOTATION MARK character replaced with the string “"” (U+0026 U+0071 U+0075 U+006F U+0074 U+003B).' is a good example of both used together |
| 19:49 | <GPHemsley> | although I see that uses fancy quotes |
| 19:52 | <Hixie> | heycam|away: yt? |
| 19:59 | <matjas> | annevk: e.g. https://gist.github.com/mathiasbynens/5760113 |
| 20:00 | <matjas> | GPHemsley: any reason not to use fancy quotes? |
| 20:00 | <GPHemsley> | matjas: Just that most of us don't. |
| 22:12 | <Hixie> | man, that bug didn't stay closed more than 10 minutes |
| 22:24 | <zcorpan> | what bug? |
| 22:32 | <Hixie> | the "incumbent script" one |