| 00:37 | <TabAtkins> | gsnedders: Thanks! |
| 05:12 | <zewt_> | misspellings to not make: "bare with me" |
| 08:48 | <Ms2ger> | "Fun fact: You can't visit http://html.spec.whatwg.org if you disable RC4 in Firefox." < eh? |
| 08:55 | <Ms2ger> | MikeSmith, thanks! |
| 08:56 | <annevk> | Ms2ger: DreamHost updated all Shared, but not VPS |
| 08:59 | <MikeSmith> | Ms2ger: cheers |
| 09:22 | <zcorpan> | Ms2ger: requiring RC4 is how we lead the web to its full potential |
| 10:34 | <jgraham> | foolip: Thanks for looking at karlt's test chnages |
| 10:51 | <hsivonen_> | annevk: fwiw, I turned off DNSSEC for hsivonen.fi. I haven't gotten around to blogging about it. TL;DR is: no real upsides considering what hsivonen.fi has in DNS, but did have a downside every 9 months due to the provider not implementing the rollover tooling the way it should be implemented |
| 12:37 | <annevk> | hsivonen: I thought there was an upside for email? |
| 12:38 | <annevk> | hsivonen: however, from everything I read it seems like something like DNSCurve would be preferable |
| 13:03 | <foolip> | jgraham: np! |
| 13:10 | <annevk> | Manishearth: you're asking the right questions |
| 13:10 | <annevk> | Manishearth: now someone will ask you if you want to write the UI Event specification :p |
| 13:10 | <annevk> | context: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27337 |
| 13:14 | <Manishearth> | annevk: Isn't DOM3 events supposed to handle that? |
| 13:14 | <Manishearth> | Also, if I were to write it, I would write "Do whatever the hell you want" :P |
| 13:15 | <Ms2ger> | Manishearth, oh no you won't :) |
| 13:16 | <annevk> | Manishearth: well DOM3 Events will be renamed since I think the editors finally agreed it has the wrong name |
| 13:16 | <Manishearth> | hah |
| 13:39 | <gsnedders> | I thought DOM3 Events went to REC ages ago and we're changing the name now? |
| 13:40 | <Ms2ger> | Heh, rec |
| 13:41 | <Ms2ger> | It's been to note, and nearly to cr |
| 13:41 | <jgraham> | It's the spec that won't die |
| 13:45 | <annevk> | Given that it doesn't even begin to answer the questions Manishearth asked in that bug it is neither worthy of REC nor CR |
| 13:48 | <gsnedders> | annevk: I never questioned that :) |
| 13:49 | <jgraham> | Just as well the W3C doesn't have a history of releasing unfinished specs |
| 13:49 | <Ms2ger> | Sarcasm from jgraham? That's a first! |
| 13:54 | <foolip> | annevk: do you recall why you dropped Text.replaceWholeText() but not Text.wholeText? |
| 13:55 | Domenic | goes to look up this strangely-named API |
| 14:00 | <Domenic> | wow Text and CharacterData are more bananas than I realized |
| 14:00 | <gsnedders> | does anyone have any stats on percentage of Linux users have gstreamer h.264 codecs installed? |
| 14:02 | <foolip> | gsnedders: I can make some up: not enough to depend on it without telling users what to do when it's not the case :) |
| 14:03 | <gsnedders> | foolip: I know that's the case! :) |
| 14:05 | <foolip> | gsnedders: unless your software is already using GStreamer as the media framework, you might also want to check for a system-installed ffmpeg/libav |
| 14:06 | <gsnedders> | foolip: all browsers use gstreamer, no? |
| 14:07 | <foolip> | gsnedders: nope, the only ones I know of are Presto (dead) and GtkWebKit |
| 14:07 | <gsnedders> | Oh. You guys all use ffmpeg/libav? |
| 14:08 | <foolip> | from memory: |
| 14:08 | <gsnedders> | I definitely had the impression that Gecko had some gstreamer impl |
| 14:08 | <gsnedders> | Though now you mention it Chrome using ffmpeg rings a significant bell |
| 14:08 | <foolip> | WebKit uses the platform framework, which is different on Mac OS X and iOS |
| 14:08 | <foolip> | Chromium uses a bundled ffmpeg |
| 14:09 | <foolip> | and my impression was that Gecko had a custom media framework |
| 14:09 | <foolip> | but there's content/media/gstreamer/ in gecko-dev |
| 14:09 | <gsnedders> | I care only about platforms that don't always have H.264 codecs installed, FWIW. |
| 14:10 | <gsnedders> | i.e., OS X/Windows/iOS/Android are for the most part irrelevant. |
| 14:10 | <foolip> | maybe ask rillian if Gecko's GStreamer stuff is always used or just to support proprietary codecs |
| 14:11 | <foolip> | gsnedders: didn't http://www.openh264.org |
| 14:11 | <foolip> | "solve" the problem? |
| 14:11 | <hsivonen> | foolip: pretty sure it is used only for proprietary codecs, only on X11 and only for media linked to via src |
| 14:11 | <hsivonen> | foolip: OpenH264 doesn't have all profiles yet |
| 14:12 | <foolip> | hsivonen: yeah, I'd be quite surprised if you used GStreamer for MSE |
| 14:12 | <gsnedders> | Also means trusting third-party binaries. Don't yet have reproducible builds. |
| 14:12 | <hsivonen> | gsnedders: http://andreasgal.com/2014/10/14/openh264-now-in-firefox/#comment-6620 |
| 14:12 | <annevk> | foolip: no not sure |
| 14:13 | <foolip> | annevk: the definition of https://dom.spec.whatwg.org/#contiguous-text-nodes is cute :) |
| 14:13 | <hsivonen> | annevk: DNSSEC has an upside for email if your MX points to a name that has DNSSEC enabled and you control the TLS cert of the SMPT server |
| 14:13 | <hsivonen> | annevk: neither is currently true in the case of hsivonen.fi |
| 14:14 | <annevk> | foolip: bit of a copout, but it was the simplest I could come up with |
| 14:14 | <hsivonen> | annevk: I hope to make both true in due course as baby care and work permit |
| 14:14 | <gsnedders> | hsivonen: still more trust than would be nice, though. can't be verified by third parties. |
| 14:14 | <hsivonen> | annevk: so maybe I'll end up re-enabling DNSSEC in the future |
| 14:14 | <foolip> | annevk: I'm plotting to remove replaceWholeText() from Blink. If you don't have data showing that wholeText is needed, I'll add a UseCounter, wait, and see. |
| 14:16 | <annevk> | foolip: I'm happy to UseCounter all the things |
| 14:16 | <hsivonen> | annevk: anyway, to re-enable DNSSEC, one of three things needs to happen: 1) I figure out how to run my own DNS server, or 2) EasyDNS figure out key sizes and rollover or 3) I locate a provider that has things figured out and is reasonable in other ways, too |
| 14:17 | <hsivonen> | gsnedders: it's also sandboxed |
| 14:17 | <hsivonen> | or maybe "will be" |
| 14:17 | <hsivonen> | I've lost track of what code ships |
| 14:19 | <hsivonen> | annevk: I'm not saying DNSSEC is totally useless. Just saying that its usefulness is very narrow on balance considering how much trouble it is |
| 14:24 | <gsnedders> | hsivonen: I'm aware. |
| 14:43 | <SteveF__> | TabAtkins: hi, if I want to add a script to a bikeshed spec can I do it .bs? |
| 14:48 | <Domenic> | annevk: fetch will auto-add Content-Length header when passing a non-streaming body, right? |
| 14:55 | <annevk> | Domenic: yeah |
| 14:55 | <annevk> | Domenic: haven't really defined that part in detail yet |
| 14:59 | <Domenic> | headers are hard |
| 15:02 | <Domenic> | annevk: relevant https://github.com/joyent/node/blob/master/lib/_http_outgoing.js#L194-L201 (and https://github.com/joyent/node/blob/master/lib/_http_incoming.js#L158-L175 ) |
| 15:05 | <annevk> | That Node is reverse engineering Mozilla should be a sign to the IETF that they are doing something wrong |
| 15:05 | <Domenic> | hehehe |
| 15:05 | <annevk> | Please tell mnot about it |
| 15:07 | <Domenic> | i wonder what's so special about set-cookie (a few lines above) |
| 15:08 | <Domenic> | hmm i see. it's an array for set-cookie; drop duplicates for the long list; and concatenate with commas for anything else |
| 15:11 | <gsnedders> | that's relatively common, and not the only header it's done for |
| 15:13 | <annevk> | I think Cookie is actually becoming the only special case |
| 15:19 | <rektide> | annevk: then which |
| 15:19 | <rektide> | annevk: which other |
| 15:19 | <rektide> | annevk: if 'neither' |
| 15:20 | <annevk> | rektide: context? |
| 15:21 | <rektide> | "annevk: inspecting event listeners kinda sucks too, so i guess it's all good" "rektide: by kind of sucks do you mean it sucks of people trying to do it, or it sucks taht people try to do it" "annevk: neither" |
| 15:23 | <rektide> | i'd like to understand what others think of the un-inspectability of event listeners |
| 15:25 | <jgraham> | It seems like being able to inspect them is anti-composition by providing global state that any script can read / mutate. |
| 15:26 | <jgraham> | If you can only touch event listeners you own there isn't the worry that someone else might unregister your listeners |
| 15:27 | <rektide> | i thought the point of HTML being declarative was that it was revealing and mutable? |
| 15:27 | <rektide> | that's always what's been so glorious about it to me- nothing is hidden |
| 15:28 | <rektide> | i'm sorry for countering- i want to be learning here, not trying to contradict |
| 15:28 | <jgraham> | I don't understand why you're sorry |
| 15:28 | <rektide> | i'm analyzing your statement, and i feel like we are in a pre-analysis mode |
| 15:28 | <jgraham> | I don't think that declarativeness and mutability are really related |
| 15:29 | <jgraham> | For example, at one time, web components promised declarativeness (at least to some degree) and encapsulation |
| 15:29 | <jgraham> | In the end it looks like they may provide neither |
| 15:30 | <rektide> | now that's an arch i wish i'd gotten to see more intimiately |
| 15:30 | <annevk> | rektide: there's a thread on www-dom that goes into the subject to some extent |
| 15:30 | <jgraham> | But that doesn't mean that everything being a giant pile of shared global state is great design |
| 15:31 | <annevk> | rektide: but basically events are an observer system, if you start attaching meaning to the observers themselves, there's something wrong with the code |
| 15:32 | <rektide> | both of you are coming at this from a distinctly use-case driven viewpoint in my perspective |
| 15:32 | <rektide> | i see your framing in terms of how one ought be building their code |
| 15:32 | <rektide> | are there other use cases you feel your statements are appropriate to? |
| 15:33 | <caitp-> | rektide: so like I said last time this came up, jquery / similar libraries will expose these event listeners, so you could just use those (or a similar strategy) to get around it |
| 15:33 | <caitp-> | if you were so inclined |
| 15:34 | <rektide> | i think there's a case to be made taht hte web is something we ought be able to learn about and meddle with |
| 15:34 | <rektide> | and thusfar, in 98% of the cases, you can show up on someone's site and begin to meddle quite effectively |
| 15:35 | <rektide> | jquery is again another case of authorship, where you as author of a site, are enforcing a system on the site |
| 15:35 | <rektide> | (rather, you are delegating to jquery an enforcement) |
| 15:35 | <rektide> | that freedom to meddle, this being US the user's agent |
| 15:36 | <jgraham> | rektide: a) that isn't true anymore sadly (most sites these days seems to use compiled, minified js that is very hard to understand as a human). However if you want to see event listeners as a user you can do that through devtools |
| 15:36 | <rektide> | giving site authors the freedom to meddle with their own event handlers |
| 15:36 | <jgraham> | Uh, b) was supposed to be the However |
| 15:37 | <rektide> | jgraham: because of the nature of event handlers, one just has to identify entrance points into the black box |
| 15:37 | <rektide> | jgraham: intercept on the way in and modify |
| 15:37 | <rektide> | jgraham: there is still a plasticity, at every level except the event handler level |
| 15:37 | <rektide> | event handlers are uniquely write-only in the whole scheme of things |
| 15:37 | <rektide> | and the defense is that it's good for authors, keeps them from doing bad things |
| 15:38 | <jgraham> | That isn't true |
| 15:38 | <jgraham> | You can't do lots of things |
| 15:38 | <jgraham> | You can't change a tag name in place, for example |
| 15:39 | <rektide> | you can't instantaneously change a tag name, but you can effectively do so via createElement, moving the children, attaching |
| 15:39 | <rektide> | there's the ability to, over steps, mutate into a desired state |
| 15:39 | <rektide> | that's a malleability to me |
| 15:39 | <jgraham> | Building larger web applications in the future will demand stronger invariants, not weaker ones |
| 15:40 | <rektide> | jgraham: it comes of as really condescending to me that architects would defend systems that create unseeable, unchangeable data-systems, because they think it's what users need |
| 15:40 | <rektide> | i understand there is data in letting users see the state they've built, in letting them manipualte it |
| 15:41 | <rektide> | but i don't see removing that capability, blocking them from it as a feature |
| 15:41 | <caitp-> | http://www.mexicosolidarity.org/sites/default/files/images/popcornhk.gif |
| 15:42 | <jgraham> | And yet the ability to enforce invariants is considered one of the most important requirements for building large, maintainable, software systems |
| 15:42 | <rektide> | and it's extremely hugely detrimental to those trying to learn the web, those who want to see and experiment with web sites that they happen upon to further their own education |
| 15:42 | <jgraham> | No, it isn't |
| 15:43 | <rektide> | ok let's take it step by step |
| 15:43 | <jgraham> | Honestly, I have other things to do. I encourage you to send email |
| 15:44 | <rektide> | in that case, i just want to drop this: it's a usescript i tried to help my friend write to make his CodeSchool experience not suck. https://gist.github.com/johnelliott/690905bb909347a56941 |
| 15:45 | <rektide> | he was not given the tools by the web to do the constructivist work he wanted |
| 15:45 | <rektide> | the web hid from him the valuable state he wanted to play with |
| 15:45 | <rektide> | his user agent was not his |
| 15:45 | <rektide> | it was the user agent of CodeSchool |
| 15:45 | <rektide> | and he was only using it |
| 15:46 | <caitp-> | template strings are going to make those so much more readable in the future |
| 15:46 | <caitp-> | can't wait :d |
| 15:46 | <rektide> | (my fork is a little better doc'ed, https://gist.github.com/rektide/b4f6d6ce9b780ed59512 ) |
| 15:47 | <rektide> | "so copy paste this content in rather than actually running it as a userscript" |
| 15:48 | <jgraham> | User scripts aren't the web, they are proprietary UA features. A user script could certainly expose a method to mess with state that authors can't. |
| 15:49 | <rektide> | i don't see why authors ought be prohibited from instrumenting themselves either |
| 15:49 | <rektide> | if i want to go wrap all my keyup handlers, i don't see why i should need jquery keeping track of all my handlers to do that |
| 15:49 | <rektide> | it's anti-constructivist to create a system which won't tell you what's in it |
| 15:49 | <rektide> | the whole point of the Document Object Model |
| 15:49 | <rektide> | as per the name |
| 15:50 | <rektide> | is to tell you the structure |
| 15:50 | <rektide> | this is obvious to me. this is basic tenants of constructivism. this is what makes things malleable. this is why the web is good. |
| 15:51 | <rektide> | this one tiny little corner is the one example where the web page refuses to report what state it holds |
| 15:51 | <caitp-> | i mean, you don't need jquery to do it, you could do it with anything |
| 15:51 | <rektide> | caitp-: it implies a monolithic developmoent practice |
| 15:51 | <rektide> | caitp-: it mandates that whomever wants to do this starts by doing this one practice |
| 15:51 | <caitp-> | heck, you could even monkeypatch Add/RemoveEventListener |
| 15:51 | <boogyman> | rektide: HTTP is stateless by default. there are ways of introducing state, but that's a decision for that "web page". |
| 15:51 | <rektide> | caitp-: but you still have to get there first |
| 15:52 | <caitp-> | it's not something everyone wants or needs to do :p |
| 15:52 | <rektide> | caitp-: it's still not modelled, it's still not something you can show up at latter and patch in |
| 15:52 | <caitp-> | but the primitives are basically there to do it |
| 15:52 | <rektide> | caitp-: but why should this one thing be the one and only place in all the HTML lands where you don't have an object model to represet the state? |
| 15:53 | <boogyman> | rektide: because http is stateless. |
| 15:53 | <rektide> | boogyman: html is nothing but state |
| 15:53 | <caitp-> | html and the dom are crazy, i wouldn't expect much from them |
| 15:53 | <rektide> | boogyman: it is the declared, mutable embodiment of state |
| 15:53 | <rektide> | boogyman: the dom is nothing but state handling |
| 15:54 | <rektide> | boogyman: i really have no idea at all what you think the http connection has to do with anything topical to the DOM not exposing an object model for one tiny corner of itself |
| 15:55 | <boogyman> | rektide: so it is your view that everything on a webpage should be mutable? including things like the scroll bar, the address bar, the bookmarks bar etc… |
| 15:56 | <rektide> | the point of the dom is to make state mutable. the defenses i've heard in here today are that: a) you can track state yourself (if you get there first and instrument/monkeypatch), b) you shouldn't need/want to track state. these seem insufficient. i would love to broaden my horizon of objections to my point of view; if you can help me find other categorical objections to my ask (model this aspect of the document), i'd love to hear |
| 15:57 | <rektide> | boogyman: those aren't the webpage, those are the user agent. and yes, those aspects fo the user agent should be an in some user agents are alterable. for instance: i can change the scheme in my OS. i can add awesomebar extensions to my browser. you're throwing some real softballs my way friend. |
| 15:57 | <rektide> | i can css3 style the scrollbar too, actually |
| 15:59 | <boogyman> | So your viewpoint is that once a fragment gets parsed by the rendering engine, that should be mutable? |
| 16:00 | <rektide> | boogyman: you rules lawyer me. i don't know what definition you are setting up to pull me on me now. i believe that it's intuitively obvious that the Document Object Model models the elements in it, and that it's failure to model the events is a clear fault in the scope of what it models |
| 16:01 | <boogyman> | I'm trying to understand your viewpoint, so I can make an accurate assessment and potentially "find categorical objections" |
| 16:02 | <rektide> | annevk: i respect you as someone who provides a lot of direction, and i really would appreciate a clash from you on this at some point. i'll try to find a way to cobble together something for a mailing list, but i was hoping to better understand the background and viewpoints ahead of time. |
| 16:04 | <rektide> | boogyman: i don't think teh view engine is concerned at all in this topic, would be my main distinction. this is an issue of the DOM, outside what renders: the DOM is the living breathing state object, and it shows us a model of that state. with this one rare peculiar exception: events. |
| 16:04 | <rektide> | parsing is incidental, is a means of getting into that state-holding system |
| 16:05 | <boogyman> | So, are you asking for mutable access to events? |
| 16:06 | <boogyman> | access of a defined event* |
| 16:06 | <rektide> | yes, i would like the Document Object Model- the thing that exposes the state- to expose events as a part of that state that it exposes |
| 16:06 | <annevk> | rektide: look at e.g. promises or observers |
| 16:06 | <annevk> | rektide: none of these systems provide a means to get to the listeners |
| 16:06 | <rektide> | well, neither of those have 'Model' in their name |
| 16:07 | <rektide> | as a quick start |
| 16:07 | <annevk> | rektide: events don't have 'Model' in their name either |
| 16:07 | <rektide> | DOM does and EventTArget is defined in the DOM |
| 16:07 | <annevk> | rektide: events, promises, and, observers are all roughly equivalent |
| 16:08 | <rektide> | this anti-constructivist trend is one i'd like to strike at, as you see |
| 16:08 | <rektide> | and it's growth is worrying |
| 16:08 | <rektide> | i agree that the problem is growing rapidly |
| 16:09 | <rektide> | i'll try to mention these others in my eventual email |
| 16:09 | <rektide> | MutationObserverTarget here we come. |
| 16:09 | <rektide> | gods above willing |
| 16:11 | <rektide> | ugg i've yet again wasted my chances to pick up intel from the enemy |
| 16:11 | <rektide> | drat |
| 16:12 | <caitp-> | (・_・ヾ)??? |
| 16:14 | <rektide> | caitp-: i was un-asiding that i've already made progressive conversation- getting annevk to go on & give me more context for this- much harder, much less likely |
| 16:15 | <rektide> | i think my first step here might be to get on hte horn with kris kowal and pick his brain on promises for a while |
| 16:16 | <rektide> | i don't necessarily want to go into that domain- DOM has Model in the name, whereas promises, in contrast, as ALWAYS a procedural instantiation- but see what weaknesses he thinks closuring everything up has |
| 16:20 | <caitp-> | well, bon voyag |
| 16:20 | <caitp-> | e |
| 16:29 | smaug____ | feels stupid. Doesn't quite understand what annevk means with data properties. How are those different to [Unforgeable] |
| 16:30 | <annevk> | smaug____: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-type IDL only supports accessor properties at the moment, afaik |
| 16:31 | <smaug____> | ah, so it would be without a getter |
| 16:32 | <annevk> | yup |
| 16:32 | <annevk> | Just trying to knock down the walls between JS and IDL |
| 16:34 | <smaug____> | would there be any reason to use data property and not just normal webidl readonly attribute? |
| 16:36 | <annevk> | It can be overkill to use the latter, especially from a self-hosting perspective, as it requires internal state |
| 16:46 | <TabAtkins> | SteveF__: Yeah, .bs is just .html with more syntax additions. You can drop in a <script> no problem. |
| 16:46 | <SteveF__> | TabAtkins: thanks |
| 16:48 | <TabAtkins> | (And as long as the start and end tags are on a line by themselves, Bikeshed will recognize them, and will avoid trying to do any "helpful" syntax conversions inside of your script.) |
| 16:48 | <SteveF__> | good to know |
| 22:17 | <TabAtkins> | Turns out that you shouldn't add things that aren't friendly with a language's tokenization rules, especially for languages without contextual tokenization algorithms. |
| 22:17 | <TabAtkins> | (Writing up the specification of unicode-range in terms of CSS tokens is tricky and dumb.) |
| 22:27 | <Hixie> | TabAtkins: oh? |
| 22:27 | <Hixie> | TabAtkins: what's the difficulty? |
| 22:30 | <TabAtkins> | For example, u+2e-30 parses as IDENT(u) NUMBER(2e-30) |
| 22:33 | <TabAtkins> | While u+2a-30 parses as IDENT(u) DIMENSION(2, a-30) |
| 22:34 | <TabAtkins> | And u+20-30 parsed as IDENT(u) NUMBER(20) NUMBER(-30) |
| 22:35 | <TabAtkins> | There are actually five parses to deal with, with different variations in the hex digits triggering the cases in a difficult-to-predict way. |
| 22:39 | <Hixie> | TabAtkins: can't you just change the tokeniser to have a U+<hex> token? |
| 22:39 | <TabAtkins> | The point was that I just *removed* the specialized unicode-range token from the tokenizer. |
| 22:39 | <Hixie> | oh |
| 22:39 | <Hixie> | why? |
| 22:39 | <TabAtkins> | Because special-purpose tokens are the devils' work, and cause confusing bugs elsewhere. |
| 22:40 | <TabAtkins> | For example, `u+a { font-weight: bold; }` is a syntax error. |
| 22:40 | <TabAtkins> | (becuase the selector parsed as a unicode-range token) |
| 22:40 | <Hixie> | wait, why are you using the same tokens for selectors as property vluaes |
| 22:40 | <TabAtkins> | Because CSS's tokenizer isn't contextually interwoven with its parser. |
| 22:40 | <Hixie> | i have a proposal! |
| 22:40 | <TabAtkins> | NOPE |
| 22:41 | <Hixie> | (why not?) |
| 22:41 | <TabAtkins> | Because that kind of interweaving makes it harder to write parsers, and requires more state. |
| 22:42 | <TabAtkins> | Also: requires knowledge of the language inside of the parser, preventing generic processing. |
| 22:42 | <Hixie> | seems pretty straight-forward to have a set of selector tokens and a set of value tokens, but ok |
| 22:42 | <TabAtkins> | Also: selectors can appear in more places than just the prelude of blocks. |
| 22:42 | <Hixie> | ah, that's an interesting one |
| 22:42 | <Hixie> | can they appear in values? |
| 22:43 | <TabAtkins> | Yes. Inside of some functions, for example. |
| 22:43 | <Hixie> | funky |
| 22:43 | <TabAtkins> | Well, when you're referring to one element from within another element... |
| 22:43 | <Hixie> | how do you handle #color vs #id ? |
| 22:43 | <Ms2ger> | #hash |
| 22:43 | <TabAtkins> | Both of those are just <hash-token>s, and contextually interpreted. |
| 22:43 | <TabAtkins> | By the property-level grammars. |
| 22:44 | <TabAtkins> | (In other words, a <hash-token> is a valid <color>. A <hash-token> is also a valid <id-selector>.) |
| 22:45 | <Hixie> | is there any string that causes a tokenisation-level error when parsing a value, short of an unexpected EOF? |
| 22:45 | <TabAtkins> | No. |
| 22:45 | <Hixie> | interesting |
| 22:45 | <TabAtkins> | If by "error" you mean "abort processing". |
| 22:45 | <Hixie> | by "error" i mean "throw property away" |
| 22:45 | <TabAtkins> | There are some strings of characters that generate guaranteed-invalid tokens. |
| 22:46 | <Hixie> | the way 'color:#ABC;color:#XYZ;' results in the second colour being dropped |
| 22:46 | <TabAtkins> | But still, throwing away is done at the property-grammar level, or block-grammar level. |
| 22:46 | <Hixie> | oh what are the guaranteed-invalid tokens? |
| 22:46 | <TabAtkins> | That's the cascade level, which is even further down the stream. |
| 22:46 | <TabAtkins> | <bad-string-token> and <bad-url-token> |
| 22:47 | <caitp> | you(SP)'ve written the grammar such that there is no sequence of valid tokens that does not result in a valid production? |
| 22:47 | <TabAtkins> | A string which contains an unescaped literal newline becomes a <bad-string-token>. An unquoted url with spaces in it becomes a <bad-url-token>. |
| 22:47 | <Hixie> | so 'color:#XYZ' is dropped at a different spot than 'color:url( \n )' ? |
| 22:47 | <TabAtkins> | caitp: For what? |
| 22:48 | <caitp> | wait, you're talking about lexer errors right |
| 22:48 | <TabAtkins> | Hixie: No, those two are dropped at the same spot - that sort of <hash-token> isn't a valid <color>, and the 'color' grammar doesn't allow <bad-url-token>. |
| 22:48 | <TabAtkins> | caitp: I use the term "tokenizer", but sure. |
| 22:48 | <Hixie> | ah, interesting |
| 22:48 | <Hixie> | cool, carry on |
| 22:48 | <caitp> | lexer, scanner, tokenizer, tic tac to |
| 22:49 | <TabAtkins> | caitp: The grammar of CSS is, like HTML, captured by the regex /.*/ |
| 22:49 | <TabAtkins> | And is then filtered down afterwards according to various production grammars. |
| 22:49 | <Hixie> | (btw, to make that true required a hell of a long time arguing in the csswg) |
| 22:50 | <Hixie> | (back in the early 2000s) |
| 22:50 | <TabAtkins> | Hixie: It still wasn't technically true when I started work on Syntax, I think. (I don't recall details, but I think there were still a few possible cases not covered by the error-recovery rules.) |
| 22:50 | <Hixie> | really? wow |
| 22:50 | <Hixie> | doesn't surprise me that we missed some |
| 22:50 | <TabAtkins> | They were arcane, iirc. |
| 22:50 | <Hixie> | we weren't being rigorous |
| 22:51 | <TabAtkins> | I'm pretty sure I talked about them on the ML when I was first writing Syntax. |
| 22:52 | <TabAtkins> | But yeah, error-recovery in grammars is a fucking trainwreck, and nobody should ever do it. Do your parsing explicitly, *then* apply grammars on top of that. |
| 22:52 | <TabAtkins> | Because at that point you can validly say "nope, you don't match, throw the whole thing out" where "the whole thing" is some construct within the file that's already well-delimited. |
| 22:53 | <Hixie> | hear hear |
