| 05:27 | <Hixie> | why does tests2.dat's "<table><plaintext><td>" have four "foster-parenting-character-in-table" errors? |
| 05:27 | <Hixie> | i don't understand |
| 05:27 | <Hixie> | oh, i see |
| 05:27 | <Hixie> | nevermind |
| 08:36 | <GPHemsley> | Hixie: "In the algorithms below, the number of days in month month of year year is: 31 if month is 1, 3, 5, 7, 8, 10, or 12; 30 if month is 4, 6, 9, or 11; 29 if month is 2 and year is a number divisible by 400, or if year is a number divisible by 4 but not by 100; and 28 otherwise." |
| 08:36 | <GPHemsley> | Hixie: That seems to suggest that every month in the year 1900 has 29 days. |
| 08:37 | <GPHemsley> | Hixie: Er, I mean... |
| 08:37 | <ChrisMorgan> | GPHemsley: the semicolons are very clear. |
| 08:37 | <GPHemsley> | Hixie: That seems to suggest that every month in a leap year that is not divisible by 100 has 29 days. |
| 08:38 | <GPHemsley> | ChrisMorgan: The semicolons are clear; it's the comma I'm worried about. |
| 08:38 | <ChrisMorgan> | Follow the semicolons. There’s no ambiguity there. |
| 08:38 | <ChrisMorgan> | Apply the rules from left to right, as is standard practice in such lists, and you get the right result. |
| 08:38 | <GPHemsley> | 29 [if month is 2 and year is a number divisible by 400], or [if year is a number divisible by 4 but not by 100] |
| 08:39 | <ChrisMorgan> | GPHemsley: comma binds more tightly than semicolon. |
| 08:39 | <Ms2ger> | It clearly needs an <ol> |
| 08:40 | <ChrisMorgan> | GPHemsley: really, the “if month is 2 and” should just be removed. |
| 08:40 | <ChrisMorgan> | s/if // |
| 08:40 | <GPHemsley> | ChrisMorgan: How do you figure that? 29 days are only in February |
| 08:41 | <ChrisMorgan> | And the range of possible values are [1, 12], of which all the rest have been accounted for. |
| 08:41 | <GPHemsley> | Ah, I see |
| 08:41 | <GPHemsley> | Yes, I suppose that's true. |
| 08:42 | <GPHemsley> | Actually, the biggest problem here is the second "if" |
| 08:43 | <ChrisMorgan> | I agree with your analysis of the parsing of the portion between the second and third semicolons, but deny it to be a problem. |
| 08:43 | <GPHemsley> | I can't see how. My bracketing is the literal interpretation. |
| 08:43 | <GPHemsley> | And that is clearly wrong. |
| 08:44 | <GPHemsley> | It should read more like "29 if month is 2, and year is a number divisible by 400 or year is a number divisible by 4 but not by 100" |
| 08:44 | <ChrisMorgan> | Because month *must* be 2 by that point. |
| 08:45 | <GPHemsley> | Ah, you're right |
| 08:45 | <GPHemsley> | Something about the way it's written suggests against following the normal order-matters reading of if/else |
| 08:46 | <GPHemsley> | to me |
| 08:46 | <GPHemsley> | "29 if year is a number divisible by 400 or year is a number divisible by 4 but not by 100" |
| 08:47 | <GPHemsley> | you could even condense it to "29 if year is a number divisible by 400 or a number divisible by 4 but not by 100" |
| 08:47 | <ChrisMorgan> | I read the entire thing as the following Python: 31 if month in (1, 3, 5, 7, 8, 10, 12) else 30 if month in (4, 6, 9, 11) else 29 if month == 2 and year % 400 == 0 or (year % 4 == 0 and year % 100 != 0) else 28 |
| 08:47 | <GPHemsley> | depending on how explicit you feel the need to be |
| 08:48 | <ChrisMorgan> | There, the `month == 2 and` part is superfluous. |
| 08:48 | <GPHemsley> | yeah, I agree with you now |
| 08:53 | <annevk> | What's all this world cup stuff? |
| 08:55 | <GPHemsley> | :) |
| 09:16 | <jgraham> | annevk: It's the reason you got up this morning and felt the overwhelming need to paint your face orange |
| 09:16 | <annevk> | Hah, far too hot for that |
| 10:37 | <smaug____> | hmm, "HTTP 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, and 504 Gateway Timeout responses" was removed, but "Any other HTTP response code not listed here must cause the user agent to fail the connection." is still there |
| 10:43 | <smaug____> | we really need some good blame for specs |
| 10:45 | <zcorpan> | is there any url that blink considers to be unresolvable? |
| 10:48 | <tobie> | darobin: webidl parser doesn't handle Promise<sequence<DomString>?>> properly (throws an "Invalid operation" error), but doesn't mind Promise<sequence<DomString?>>. Any ideas why offhand? |
| 10:48 | <zcorpan> | "data:x," maybe? |
| 10:52 | <ChrisMorgan> | zcorpan: how about http://www.invalid/ |
| 10:52 | <ChrisMorgan> | .invalid is reserved for the purpose. |
| 10:53 | <zcorpan> | ChrisMorgan: it doesn't fail to resolve on the url parser level |
| 10:53 | <zcorpan> | it fails in dns lookup |
| 10:54 | <ChrisMorgan> | Hokay. |
| 10:54 | <tobie> | darobin: Just. Nevermind. |
| 11:02 | <darobin> | tobie: okay :) |
| 11:12 | <annevk> | zcorpan: http://test:test/ |
| 11:13 | <annevk> | zcorpan: iirc |
| 11:13 | <annevk> | yup, I win |
| 11:13 | <zcorpan> | annevk: how do you tell that it doesn't resolve? |
| 11:13 | <annevk> | protocol != http |
| 11:14 | <zcorpan> | ah. thanks! |
| 11:14 | <annevk> | in theory :link shouldn't match I think |
| 11:15 | <zcorpan> | it does though |
| 11:15 | <annevk> | oh that was removed |
| 11:16 | <annevk> | now the requirement is simply <a href> |
| 11:17 | <zcorpan> | .protocol is http: in gecko when url fails to resolve (but .href returns the input string) |
| 11:19 | <annevk> | Yeah, inconsistency all over |
| 11:20 | <annevk> | URL Standard has requirements, but nobody is biting |
| 11:34 | <zcorpan> | the spec's bug filer's textarea's resizer thumb seems like it's in the wrong corner |
| 11:47 | <tobie> | darobin: was using <pre> instead of <script type=text/plain> for WebIDL blocks |
| 11:47 | <darobin> | ah, yeah, that will bite your arse off |
| 12:20 | <SimonSapin> | zcorpan: depends what you mean by resolve, but http://dev.w3.org/csswg/css-values/#about-invalid sounds related |
| 12:22 | <zcorpan> | SimonSapin: as in "fail to parse" |
| 13:22 | <darobin> | tobie: catchy name, for this "http://www.w3.org/2001/02pd/rec54#ED"; property uh? |
| 13:52 | <tobie> | darobin: don't expect me to understand what the name of the property is by reading this thing. |
| 13:52 | <darobin> | well it's easy! |
| 13:53 | <darobin> | pick a domain, then a random year, a mixture of random letters and numbers, then an anchor and a human-oriented shortname |
| 13:53 | <tobie> | darobin: my eyes can't get off of all the urls and namespaced props. sorry. |
| 13:53 | <darobin> | welcome to the semantic web! |
| 13:54 | <darobin> | oh you wish that were namespaced — it's not |
| 13:54 | <darobin> | RDF doesn't have namespaces |
| 13:54 | <darobin> | that *the* name |
| 13:54 | <tobie> | yeah, thankfully, this subset of semantic want parses as XML. |
| 13:54 | <darobin> | a blessing in disguise |
| 13:54 | <darobin> | I reckon this is the first time I see someone thankful for RDF/XML |
| 13:54 | <tobie> | The fact I'm thankful something parses as XML says a lot about how I feel about it. |
| 13:55 | <tobie> | Well granted thee are descent xml to json converters |
| 13:56 | <jgraham> | That's a HTML formatting, generated using XSLT, or an RDF schema that models the W3C process? There's so much wrong there I don't know where to start |
| 13:57 | <tobie> | At least the data is avaiable. |
| 13:58 | <tobie> | I also like my object in JS to look like this: obj["contact:homePage"][0]["$"]["rdf:resource"] |
| 13:58 | <tobie> | so much fun. |
| 13:59 | <annevk> | darobin: there was an idea about putting PSL into DNS, but nothing that really gained traction |
| 14:00 | <darobin> | annevk: I thought of that, but what's the advantage? |
| 14:00 | <annevk> | darobin: decentralized |
| 14:01 | <Ms2ger> | ... extensibility? |
| 14:01 | <annevk> | darobin: however, might require a level of understanding not present there |
| 15:12 | <Domenic> | Does anyone have the TL;DR on what makes <script> parsing insane? seems like a mathiasbynens type thing :P |
| 15:12 | <annevk> | Domenic: it's a third of the states? |
| 15:12 | <mathiasbynens> | Domenic: document.write |
| 15:13 | <Domenic> | annevk: yeah, I guess that's too short :P. mathiasbynens: ahhh that makes sense. |
| 15:13 | <Domenic> | there are other issues too right? e.g. the </script> detection |
| 15:14 | <mathiasbynens> | http://mths.be/etago |
| 15:14 | <SamB> | there's document.write(), stuff like the <!-- --> (though CSS has that too), the fact that hardly anything needs to be escaped inside <script> (</script> is the main thing that comes to mind), etc? |
| 15:14 | <jgraham> | Yeah, the double dash stuff is the worst |
| 15:15 | <Domenic> | so if we were designing <module> from scratch, we would still need no-escaping and </module>, but we could remove <!-- --> and document.write()... maybe. |
| 15:18 | <annevk> | Domenic: it seems like a very big XSS hole to have <module> |
| 15:18 | <Domenic> | annevk: ah yeah, true :(( |
| 15:18 | <jgraham> | Yeah, script type="module" seems way safer |
| 15:18 | <Domenic> | annevk: but hey, I thought we gave up that battle once <link rel="import"> arrived? :P |
| 15:19 | <annevk> | Domenic: also, if <module> has different characteristics from <script>, it seems even harder for people to deal with the hazard |
| 15:19 | <jgraham> | Please tell me that thread ended with people agreeing that link rel=import was a bad idea? |
| 15:19 | <Domenic> | annevk: which hazard? |
| 15:19 | <annevk> | Domenic: XSS |
| 15:20 | <Domenic> | jgraham: the hope was that <module> would be the new <script>, which kind of requires the easy-path to be at least as short to type, instead of having to add extra characters. I.e., trying to avoid the annoyingness of "use strict" or <!DOCTYPE html>. |
| 15:21 | <Domenic> | Although I guess it is kind of true that if implementers are shipping <link rel="import"> without XSS concerns they have already decided that blacklist-based XSS is not a use case they want to support. |
| 15:21 | <Domenic> | s/XSS/XSS prevention/ |
| 15:21 | <jgraham> | It's possible that it also shows they dropped the ball and failed to consider it |
| 15:22 | <jgraham> | security isn't a use case |
| 15:22 | <annevk> | Domenic: I think Hixie is right that the annoying thing is that modules require syntax in the first place |
| 15:22 | <annevk> | Domenic: out-of-band syntax, that is |
| 15:23 | <Domenic> | annevk: I don't really think so. I have no issues with that part of the design. |
| 15:23 | <Domenic> | I.e. practically speaking it doesn't cause me any grief. |
| 15:24 | <Domenic> | worst case-scenario, we get no new toys and I just do <script>System.import('bootstrap-module')</script> |
| 15:24 | <jgraham> | So this conversation rather suggests that it does cause grief… |
| 15:25 | <jgraham> | I mean you can't simultaneously say it's not a problem to require syntax and that <script module> is too much syntax |
| 15:26 | <jgraham> | or type=module |
| 15:26 | <jgraham> | I don't know what back-compat stoy you want |
| 15:28 | <Domenic> | the current party line is that <script type="module"> is the transitional back-compatible thing, but eventually when all browsers implement <module> people can just use that instead. clearly that is pretty naive, as various aspects of this conversation reveal. but it seems possible at least. |
| 15:29 | <SamB> | why would there ever be a time when all browsers have implemented any particular new thing? |
| 15:29 | <annevk> | I don't get the whole transitional party line. |
| 15:29 | <annevk> | I have heard Dave argue it, but no other feature has ever had such treatment |
| 15:30 | <annevk> | If you want <module>, make that happen and create a polyfill with the former. Don't add two features to the platform that require indefinite support |
| 15:30 | <jgraham> | Didn't we just decide that <module> is XSS unsafe? |
| 15:31 | <annevk> | jgraham: arguably we have introduced a lot that is XSS unsafe, so the weight of that argument is unclear |
| 15:31 | <SamB> | jgraham: is that because we already have lots of anti-XSS stuff that has never heard of <module>, or is it something more fundamental? |
| 15:32 | <jgraham> | annevk: What have we introduced recently? |
| 15:32 | <annevk> | jgraham: various <video> event handlers |
| 15:34 | <jgraham> | Hmm, that does seem suboptimal |
| 15:35 | <SamB> | doesn't flagrantly XSS-unsafe stuff usually end up crippled in fairly short order? |
| 15:37 | <Domenic> | SamB: example? |
| 15:38 | <SamB> | well, okay, maybe not "fairly short" |
| 16:35 | <Hixie> | the difference is that <module> introduces radically new (and crazy) parsing rules |
| 16:35 | <Hixie> | that's why it's orders of magnitude more scary for security than new event handlers |
| 16:36 | <SamB> | ... why would anyone let non-legacy parsing crazy into the HTML spec? |
| 16:37 | <jgraham> | Because they want module to work like script |
| 16:37 | <jgraham> | but to not be called script |
| 16:37 | <jgraham> | For some reason |
| 16:38 | <SamB> | but, they can't just use script's parsing rules because why? |
| 16:40 | <jgraham> | script has crazy parsing rules already |
| 16:40 | <jgraham> | So making those rules apply in a different context is new and crazy |
| 16:41 | <SamB> | not *radically* new and crazy, surely? |
| 16:42 | <SamB> | so I'm assuming Hixie meant something worse than that |
| 16:48 | <Hixie> | they'd be radically new because they'd apply to <module>, which they didn't apply to before |
| 16:48 | <Hixie> | and either they're crazy because they're like <script>, or they're crazy because they're specifically _not_ like <script> |
| 16:48 | <Hixie> | you're damned either way if you introduce a new script-containing element |
| 16:49 | <Hixie> | it's just a bad idea and we should stay away from anything that results in multiple script-capable elements |
| 16:49 | <Hixie> | (this would all have been much easier if the ES group had reached out before designing their module thing, to coordinate with us and figure out what was reasonable and what was not.) |
| 16:50 | <caitp> | you've still got a few months to get them to change their minds about things =) |
| 17:07 | <SamB> | Hixie: hmm, refactoring those words from saying "</script>" to saying "</script> or </module>, respectively" doesn't seem like a radical CHANGE, just a stupid one |
| 17:08 | <Hixie> | SamB: it's radical in that it radically changes how <module> is parsed, but if you're just arguing the semantics of how i phrased it, i'll concede :-) |
| 17:08 | <SamB> | I mean, would it add a huge amount of logic? not as far as I can see. would it give bizarrely different parse results in new and old browsers? hell yes. |
| 17:08 | <Hixie> | "bizarrely different parse results in new and old browsers" seems "radical" to me :-) |
| 17:09 | <Hixie> | and "crazy" too :-) |
| 17:09 | <SamB> | anyway, evil like <script> parsing should be kept strictly to legacy things |
| 17:09 | <SamB> | Hixie: well, the *rules* aren't radically new, the *behaviour* is |
| 17:09 | <Hixie> | i don't understand the difference, but this seems like splitting hairs so i'll extricate myself from the conversation now :-P |
| 17:10 | <Hixie> | <script> isn't going to be legacy, though, however much the ES folk want it to be |
| 17:10 | <Hixie> | we'll be using non-module scripts for decades |
| 17:10 | <SamB> | well, I mean, they shouldn't be encouraged to BREED |
| 17:10 | <Hixie> | doesn't matter how much you encourage them |
| 17:10 | <SamB> | it's legacy in the sense that crazy rules are a legacy |
| 17:10 | <Hixie> | oh well sure |
| 17:11 | <SamB> | not so much in the sense of "expected to die at some point" |
| 17:12 | <SamB> | kind of like that one argument to WinMain that's leftover from Win16 |
| 17:12 | <SamB> | hPrevInstance |
| 17:13 | <Hixie> | well the difference is people ignore hPrevInstance now |
| 17:13 | <SamB> | true |
| 17:13 | <Hixie> | whereas <script> is going to be actively used for decades |
| 17:13 | <SamB> | maybe that's got more bearing on the <!-- --> part |
| 17:14 | <SamB> | anyway, I don't think hPrevInstance can possibly have a value in win32 |
| 17:14 | <Hixie> | it's always NULL, no? |
| 17:14 | <SamB> | er, yeah, a non-0 value I mean |
| 17:15 | <SamB> | on account of win32 having per-process address spaces |
| 17:17 | SamB | should stop babbling |
| 17:34 | <Hixie> | can someone sanity check me?: in |An end tag whose tag name is "form"|, in the "in body" insertion mode, the "Otherwise" clause of step 2 of the first branch is redundant with step 1, right? |
| 17:36 | <jgraham> | Hixie: Well it doesn't make any sense at least |
| 17:37 | <jgraham> | Since it's an otherwise on an infallible operation |
| 17:37 | <Hixie> | yeah |
| 17:37 | <Hixie> | i'll just remove that second sentence of step 2 |
| 17:38 | <SamB> | or, make a note like "I am invincible!" |
| 17:38 | <TabAtkins_> | Ms2ger: What's this about custom DTDs and the CSSWG yesterday? |
| 17:39 | <SamB> | what does a DTD have to do with anything |
| 17:39 | <SamB> | I thought a DTD was just a way to make your SGML editor do sensible autocompletion |
| 17:39 | <SamB> | and your SGML parser tell you when you screwed up |
| 17:40 | <Ms2ger> | TabAtkins_, see http://www.w3.org/Style/ |
| 17:41 | <SamB> | (Speaking of, what things (if any) do you folks use to edit SGML and XML, respectively?) |
| 17:41 | <Hixie> | emacs. |
| 17:42 | <hober> | no one actually edits sgml anymore :) |
| 17:42 | <Ms2ger> | s/anymore// |
| 17:42 | <TabAtkins_> | SamB: The <!-- --> thing in CSS isn't insane at all, luckily - they get parsed as tokens, and ignored at the top-level of the stylesheet. No big deal. |
| 17:43 | <TabAtkins_> | Ms2ger: I... I see. |
| 17:43 | <SamB> | I feel like it's kind of a shame about SGML; maybe SGML would have gotten more love if the specs hadn't been locked up in the ISO ... |
| 17:43 | <jgraham> | It's OK, once hober finishes his emacs HTML mode you won't need DTDs to enable syntax checking and autocomplete :p |
| 17:43 | <SamB> | I was actually wondering what modes ;-P |
| 17:44 | <Hixie> | SGML had two serious flaws, imho |
| 17:44 | <Hixie> | first, it was WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY more complicated than necessary |
| 17:44 | <Hixie> | second, it was WAAAAAY not powerful enough |
| 17:44 | <SamB> | and I didn't ask about HTML precisely because of the lack of an adequate mode for actual HTML, rather than for it's fictioanl SGML forms |
| 17:45 | <SamB> | Hixie: yeah, SGML declarations do seem kind of dopey |
| 17:46 | <SamB> | there's, maybe, *one* good thing about them: they managed to retrofit SGML to allow a declaration for XML ... |
| 17:46 | <SamB> | anyway use psgml and nxml/rng |
| 17:47 | <Hixie> | XML has two serious flaws, imho |
| 17:47 | <SamB> | yeah? |
| 17:47 | <Hixie> | first, it was WAY more complicated than necessary |
| 17:47 | <hober> | jgraham: :/ |
| 17:47 | <Hixie> | second, it was WAAAAAAAAY not powerful enough |
| 17:47 | <SamB> | Hixie: well, at least that's a lot less As in the first flaw |
| 17:48 | <Hixie> | yup :-) |
| 17:48 | <TabAtkins_> | Yeah, XML isn't *that* over-complicated. |
| 17:48 | <TabAtkins_> | Just a good bit. |
| 17:48 | <SamB> | Hixie: what are the extra As in the second flaw for? |
| 17:48 | <Hixie> | it's less powerful than SGML |
| 17:48 | <TabAtkins> | XML is weaker than SGML. |
| 17:48 | <Hixie> | so... |
| 17:48 | <gavinc> | No over lapping tag spans :( |
| 17:49 | <SamB> | Hixie: yes, well, isn't DTD almost counter to the whole XML idea anyway |
| 17:49 | <TabAtkins> | SGML had overlapping tags? |
| 17:49 | <TabAtkins> | Non-tree data structure? |
| 17:50 | <SamB> | all I know of SGML I learned from James Clark's implementation ;-P |
| 17:50 | <SamB> | well, maybe not quite, but I wouldn't know much about anything he didn't implement |
| 17:50 | <Hixie> | if we restrict ourselves to tree structure use cases (which is a big restriction which we can come back to), XML is either too complicated because of all the DTD baggage, or not powerful enough because DTDs can barely describe the simplest of conformance requirements. |
| 17:51 | <Hixie> | man, the html parser spec has an inordinate number of negated conditions |
| 17:51 | <Hixie> | and i keep forgetting to negate them in my code |
| 17:51 | <Hixie> | leading to annoyingly hard-to-debug bugs |
| 17:52 | <SamB> | basically I think we should just forget about DTD except *maybe* as a vehicle for defining those, er, shorthand things |
| 17:52 | <SamB> | RNG is much, much better |
| 17:52 | <SamB> | (though maybe harder to explain) |
| 17:52 | <gavinc> | Entities are what DTDs get you that RNG still doesn't |
| 17:52 | <SamB> | that's the word! |
| 17:52 | <jgraham> | Hixie: You know, you are the person on the planet least likely to get sympathy there |
| 17:53 | <gavinc> | but entites introduce all sorts of nastyness |
| 17:53 | <Hixie> | jgraham: :-) |
| 17:53 | <SamB> | gavinc: yeah, the nastyness is why I said "*maybe*" |
| 17:53 | <gavinc> | since what most people want is names for hard to remember unicode characters, and what you get is a complex include system |
| 17:53 | <Hixie> | i've found a few bugs in the parser with this nutty project of mine |
| 17:53 | <Hixie> | so i feel like i'm being productive |
| 17:54 | <SamB> | Hixie: then, you just need to figure out how to compile it back to English |
| 17:54 | <Hixie> | unfortunately i'm not implementing the full parser |
| 17:54 | <Hixie> | e.g. i'm ignoring all the script execution stuff |
| 17:55 | <SamB> | darn it, why do w3.org / html5.org have so much higher pagerank for this phrase anyway |
| 17:55 | <Hixie> | which phrase? |
| 17:55 | <SamB> | An end tag whose tag name is "form" |
| 17:58 | <Hixie> | wow, yeah, that's sad |
| 17:59 | <SamB> | anyway, jgraham is totally right about that being nonsense |
| 17:59 | <SamB> | if you fail to set the form element pointer, I think it's time to die to SIGSEGV |
| 17:59 | <Hixie> | k. it's gone. |
| 18:14 | <Hixie> | TabAtkins: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503 - any chance we could have an efficient 'display-*' value for <br>? |
| 18:28 | <TabAtkins> | Yeah, need to take that back to the CSSWG. Will do so. |
| 18:28 | <Hixie> | ta |
| 18:28 | <SamB> | what makes a CSS value efficient? |
| 18:28 | <Hixie> | see dbaron's comment in that bug |
| 18:29 | <annevk> | "What the actual fuck." <3 Mark Pilgrim |
| 18:37 | <Hixie> | i wonder what he thinks would be better |
| 18:37 | <Hixie> | an @rule in CSS? |
| 18:38 | <TabAtkins> | What's the context of that one? |
| 18:38 | <TabAtkins> | annevk: Do you have any examples of multipe-documents-in-one-window-sharing-fonts besides Imports? Imports are already kinda-sorta same document, right? |
| 18:40 | <Hixie> | blink-dev |
| 18:40 | <Hixie> | does everyone agree that "If there is no adjusted current node" is equivalent to "If the stack of open elements is empty" ? |
| 18:42 | <SamB> | oh, why the heck did I get <br> mixed with <hr> ... |
| 18:43 | <SamB> | fragment case is a bit tricky to follow ... processing ... |
| 18:44 | <SamB> | also apparently "fragment case" is a technical term you didn't use here |
| 18:45 | SamB | can't follow where it goes from "if there is a context element" to just "the context element" |
| 18:46 | <SamB> | Hixie: I guess it does |
| 18:48 | <SamB> | Hixie: what happened to adding caution tape around any mention of direction WRT stacks |
| 18:51 | <Hixie> | SamB: file a bug if you're serious about that :-) |
| 18:52 | <Hixie> | (with concrete suggestions that don't make the spec even harder to read...) |
| 18:52 | <SamB> | oh, so no yellow tape then? |
| 18:52 | <SamB> | darn it |
| 18:52 | <Hixie> | i'm happy to do it, i just don't know how exactly |
| 18:54 | <Ms2ger> | The annoying thing is that it's not a stack, obviously :) |
| 18:54 | <SamB> | Ms2ger: oh |
| 18:54 | <SamB> | really? |
| 18:55 | <SamB> | it's not just a magnetic stack or something? |
| 18:55 | <SamB> | anti-gravity stack, maybe? |
| 18:56 | <Ms2ger> | It admits random access |
| 18:58 | <Hixie> | yeah, it's a stack where every now and then you just have to fiddle with it arbitrarily |
| 18:58 | <Hixie> | removing, swapping nodes around, all kinds of crazy stuff |
| 18:59 | <caitp> | just imagine if the parser didn't have to swap nodes around |
| 18:59 | <caitp> | what if... |
| 19:01 | <Ms2ger> | So, "an array" |
| 19:01 | <Ms2ger> | Or a vector |
| 19:03 | <SamB> | meh, I do stuff like that to stacks IRL all the time ;-P |
| 19:03 | <SamB> | though the most accessible item is at the TOP of the stack |
| 19:03 | <Hixie> | caitp: it would be awesome |
| 19:03 | <Hixie> | caitp: (also, it would not be compatible with most of the web) |
| 19:03 | <Hixie> | are we agreed that when the spec says "reprocess the token", it means to go through tree construction dispatcher again? |
| 19:05 | <SamB> | Hixie: hmm, the diagram in "Overview of the parsing model" has a green block obscuring part of it ... |
| 19:05 | <SamB> | TabAtkins: I blame you guys for this! |
| 19:07 | <Hixie> | oh wow, yeah |
| 19:07 | <Hixie> | oops |
| 19:07 | <Hixie> | TabAtkins: does HTML have a way to make boxes not overlap floats yet? |
| 19:07 | <Hixie> | i remember mozilla implemented something to do this way back when |
| 19:07 | <Hixie> | as a hack |
| 19:08 | <SamB> | you mean like a -moz- property or value? |
| 19:09 | <Hixie> | yeah |
| 19:19 | <TabAtkins> | Hixie: Only via BFC creation. |
| 19:19 | <Hixie> | bfc? |
| 19:19 | <TabAtkins> | All the methods of which have side-effects. |
| 19:19 | <TabAtkins> | Block Formatting Context. |
| 19:19 | <Hixie> | ah |
| 19:20 | <Hixie> | bumemr |
| 19:20 | <TabAtkins> | overflow: anything-but-visible is the most common way. |
| 19:21 | <Hixie> | what's anything-but-visible? |
| 19:21 | <Hixie> | i wonder how to fix this rendering issue |
| 19:22 | <Hixie> | maybe just make the float a higher z-index for now |
| 19:23 | <TabAtkins> | Hixie: It's... what it sounds like? |
| 19:23 | <Hixie> | what counts as 'visible'? |
| 19:23 | <Hixie> | does it mean "don't show a scroll bar if the bottom of this image is the only thing that overflows and the bottom of the image is fully transparent", for instance? |
| 19:24 | <TabAtkins> | Hixie: The "visible" keywords. I'm being very literal. |
| 19:24 | <TabAtkins> | keyword, sorry. |
| 19:24 | <Hixie> | oh, not a specific keyword "anything-but-visible" |
| 19:24 | <Hixie> | ok |
| 19:24 | <TabAtkins> | Hahaha, of course not |
| 19:24 | <Hixie> | sorry, i thought you were being more literal than you were :-) |
| 19:24 | <TabAtkins> | That's too silly even for CSS. |
| 19:24 | <Hixie> | hey i dunno man, there's all kinds of new keywords in CSS these days that i've never heard of :-) |
| 19:25 | <Hixie> | setting 'overflow:hidden' on every paragraph in the HTML spec seems like a bad call |
| 19:25 | <Hixie> | z-index seems bad too though |
| 19:25 | <Hixie> | ugh |
| 19:25 | <Hixie> | i really just want a "warp my block background around floats" option |
| 19:25 | <Hixie> | oh well |
| 19:26 | <SamB> | what would happen if you *did* write "display: anything-but-visible"? |
| 19:26 | <SamB> | that's not "display: visible" |
| 19:26 | <SamB> | er. or "overflow:", whatever |
| 19:26 | <Hixie> | it would get ignored |
| 19:26 | <Hixie> | since it's not valid |
| 19:26 | <Hixie> | same as overflow: aiohfgoaiehjdzl; |
| 19:26 | <SamB> | right. |
| 19:27 | <Hixie> | or alkfjalksjf: alfhjalksfj |
| 19:27 | <SamB> | yeah, any idiot could tell that last one wouldn't do anything |
| 19:28 | <SamB> | there being no "alkfjalksjf" property and all |
| 19:30 | <Hixie> | are we agreed that "Pop an element from the stack of open elements, and then keep popping more elements from the stack of open elements until" implies that at least two elements will be popped? |
| 19:30 | <Domenic> | no |
| 19:30 | <Domenic> | sounds like at least one |
| 19:30 | <TabAtkins> | What's the float thing you're trying to do? |
| 19:31 | <Hixie> | TabAtkins: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26079 |
| 19:31 | <SamB> | Hixie: me either, uness the "until" specifically refers to an *additional* element |
| 19:31 | <Hixie> | hmm... i guess |
| 19:31 | <Hixie> | i should make that clearer then |
| 19:36 | <TabAtkins> | Hixie: I've been looking through sections, but haven't fouind an example of such yet. |
| 19:36 | <TabAtkins> | Hixie: I'm also with the "at least one" interpretation. |
| 19:37 | <Hixie> | TabAtkins: the link in that bug is to a section with an image |
| 19:37 | <TabAtkins> | I'd say "pop elements from the stack of open elements until .... If this would pop less than two, pop two elements." |
| 19:38 | <TabAtkins> | Hm, I don't see it. |
| 19:39 | <Hixie> | search for "The input to the HTML parsing process consists of" |
| 19:39 | <Hixie> | and look to the right |
| 19:39 | <Hixie> | it's in 12.2.1 Overview of the parsing model |
| 19:40 | <TabAtkins> | Looks like that's not in the pointed-to section of the multipage. ^_^ |
| 19:41 | <TabAtkins> | Ok, I see. |
| 19:41 | <TabAtkins> | We put overflow:hidden on all .note/.example/etc in the CSSWG stylesheet. |
| 19:41 | <TabAtkins> | Precisely to fix this. |
| 19:41 | <Hixie> | ah |
| 19:41 | <Hixie> | i think that would break all my fancy label things |
| 19:41 | <Hixie> | since they overflow |
| 19:41 | <TabAtkins> | Ah, true. |
| 19:42 | <TabAtkins> | WELP |
| 19:43 | <Hixie> | hm? |
| 19:43 | <SamB> | shouldn't it just be possible to make boxes extend to the right until they hit a float *or* hit the parent's edge? |
| 19:43 | <TabAtkins> | SamB: It *should* be, yes. But it's not. |
| 19:43 | <Hixie> | samb: it's non-trivial, but that's what i'd like. Actually what i'd like is that they wrap their backgrounds around. |
| 19:43 | <Hixie> | but that's even less trivial |
| 19:44 | <SamB> | wrap their backgrounds around, you say? |
| 19:44 | <TabAtkins> | We have a trial value (with a purposely-bad name) in the Sizing spec that does this, but it's underspecified, as it only addresses sizes, not the position-shifting that BFCs do. |
| 19:44 | <SamB> | sounds like you want to print it out, cut out the pieces, and then glue them together ;-P |
| 19:44 | <Hixie> | and wrap their borders, for bonus points |
| 19:45 | <SamB> | TabAtkins: what about position shifting would it need to address? |
| 19:45 | <TabAtkins> | Those all come as part of a package, Hixie. |
| 19:45 | <Hixie> | even border-radius with border images? :-) |
| 19:45 | <TabAtkins> | SamB: If you have a left-floated item next to a BFC, the BFC not only shrinks its width, but also shifts to the right to get out of the way. |
| 19:45 | <SamB> | ouch |
| 19:45 | <TabAtkins> | Hixie: If your border images don't extend out of the border geometry, sure. |
| 19:46 | <SamB> | left floats FTL :-( |
| 19:46 | <TabAtkins> | Or if you're willing to add margin to address that. |
| 19:46 | <TabAtkins> | Left floats the most common float. |
| 19:46 | <SamB> | is it? |
| 19:46 | <Hixie> | TabAtkins: just so we're clear, i'm not talking about just resizing, i'm talking about wrapping around the float(s) |
| 19:46 | <TabAtkins> | I don't know what you mean, in that case. |
| 19:46 | <Hixie> | which would mean the border now has multiple corners, some concave, some convex... |
| 19:46 | <TabAtkins> | Oh! |
| 19:46 | <TabAtkins> | No. |
| 19:46 | <TabAtkins> | ^_^ |
| 19:46 | <SamB> | oh, yeah, that'd be even nicer |
| 19:46 | <Hixie> | that's why it's worth bonus points |
| 19:47 | <Hixie> | many, many bonus points... |
| 19:47 | <SamB> | you'd need extra border- stuff to put special background on the concave corners |
| 19:47 | <Hixie> | well crap |
| 19:48 | <Hixie> | the "any other end tag" step of the foreign parsing mode totally messes with all my optimisations |
| 19:48 | <SamB> | I mean, if you wanted to do one of the silly raster-based box things like people used to do with <table> |
| 19:48 | <Hixie> | "If node's tag name, converted to ASCII lowercase, is the same as the tag name of the token"! |
| 19:48 | <TabAtkins> | Just match CSSWG's style for notes/examples/etc? They were put together by actual designers, and have gotten lots of compliments over the years we've used them. |
| 19:48 | <Hixie> | i guess i'd better keep multiple tag names around... |
| 19:48 | <SamB> | Hixie: shouldn't the node already have a lowercased name? |
| 19:48 | <Hixie> | SamB: not in foreign content |
| 19:48 | <SamB> | darn |
| 19:49 | <SamB> | well then why does the close tag not have to match? |
| 19:49 | <Hixie> | because if you write <svg><CLIPPATH></clippath> the two "clippath" tags have to match |
| 19:50 | <Hixie> | but the element is actually <clipPath> |
| 19:50 | <Hixie> | i guess i'll just store a lowercased tag name |
| 19:51 | <SamB> | if you only know the case because you looked it up in a table, it seems almost silly to store the proper-cased version in the tree node |
| 19:51 | <Hixie> | well the proper-cased version is what you need for everything but parsing |
| 19:52 | <SamB> | ... what exactly do you use the tree for in your implementation? |
| 19:53 | SamB | starts imagining strings with memoized lowercasing |
| 19:53 | <SamB> | hmm, do/can they have interning in JS? |
| 19:54 | <Hixie> | well e.g. a browser would need to know the right case to distinguish a <clipPath> element from a <clippath> element (the latter of which does nothing, the former is part of SVG) |
| 19:54 | <SamB> | or do they have those silly mutable strings like elisp has |
| 19:54 | <SamB> | Hixie: certainly |
| 19:57 | <SamB> | Hixie: but, uh, can't they just inherit the names from the traits object? |
| 19:57 | <Hixie> | the what now? |
| 19:57 | <SamB> | I think they mistakenly call them "prototypes" in JS? |
| 19:57 | <SamB> | darn, I forgot the ;-P |
| 19:58 | <Hixie> | who's using JS? |
| 19:58 | <SamB> | hmm |
| 19:58 | <SamB> | hmm, are you implying that there's going to be a browser that supports embedded SVG but doesn't represent its DOM using JS objects? |
| 19:59 | <Hixie> | no browser represents its DOM using JS objects |
| 19:59 | <Hixie> | that would be a performance disaster. |
| 19:59 | <TabAtkins> | We inch closer to that every day. |
| 20:00 | <TabAtkins> | dom.js is a project we keep shooting for. |
| 20:00 | <SamB> | I thought they just used magic pixie dust to make the fixed-layout stuff work |
| 20:00 | <SamB> | so the C++ code can keep pretending it's not a JS object |
| 20:02 | <SamB> | I guess JS doesn't have a way to pre-specify "slots" to be used for a certain class (not OO class, just the regular meaning) of objects? |
| 20:03 | <Hixie> | this is all academic in this instance, since my parser is not in JS |
| 20:10 | <SamB> | point |
| 20:11 | <SamB> | really what I meant is: why would you have to store the name in each node, rather than in a single thing that describes all elements of that name? |
| 20:12 | <SamB> | except for elements you've never heard of |
| 20:13 | <Ms2ger> | Ah, blink: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/nzRY-h_-_ig |
| 20:13 | <SamB> | Hixie: ... but, do you think you're the only one who'se allowed to talk "as if" the implementation must the JS DOM to represent the document? |
| 20:13 | <SamB> | +use |
| 20:13 | <SamB> | even while not actually meaning that |
| 20:14 | <SamB> | (Yes, I went there: I just specified the "as if" rule backward.) |
| 20:14 | Ms2ger | specifies as if SamB made sense |
| 20:14 | <SamB> | sorry :-) |
| 20:14 | SamB | will go back to easy things, like maintaining GDB packaging |
| 20:18 | <Hixie> | SamB: well i'm only storing a pointer, obviously |
| 20:18 | Ms2ger | points at Hixie |
| 20:19 | <SamB> | Hixie: what language *are* you using again? |
| 20:19 | <TabAtkins> | objectpascal, obvs. |
| 20:19 | <SamB> | hmm. |
| 20:19 | <TabAtkins> | Hixie's favorite language. |
| 20:21 | <SamB> | yeah, I imagine there's a reason it has such a happy-seeming contingent of user despite being virtually unmarketed for ... a long time now? |
| 20:21 | <SamB> | *users |
| 20:22 | <SamB> | huh |
| 20:22 | <SamB> | Need to get 17.1 MB of archives. |
| 20:22 | <SamB> | After this operation, 161 MB of additional disk space will be used. |
| 20:22 | <Ms2ger> | Uncompressed? |
| 20:22 | <SamB> | I guess they ship sources for the libs? |
| 20:23 | <SamB> | that's for fpc |
| 20:24 | <TabAtkins> | SamB: Shrug, I'm a happy Common Lisper. We all have our kinks. |
| 20:24 | <Hixie> | i think i'd be a C++ head if i hadn't happened to start with pascal |
| 20:24 | <Hixie> | they're very similar, at the end of the day |
| 20:24 | <SamB> | Common Lisp always leaves me overloaded trying to figure out how to go about my business :-( |
| 20:25 | <SamB> | too many choices |
| 20:25 | <Hixie> | in terms of what they're good at and their performance characteristics |
| 20:25 | <Hixie> | but having started in pascal and then later delphi, i find C++ to be really ugly |
| 20:25 | <TabAtkins> | "There's an infinity of ways to do it, and that's not counting readtable hacking." |
| 20:25 | <Ms2ger> | I think everyone finds C++ ugnly |
| 20:25 | <Ms2ger> | ugly |
| 20:26 | <SamB> | I think Object Pascal has some important advantages; optimizations implemented in the compiler not being one of them. Unless it makes the compiler run way faster, which it might ;-) |
| 20:26 | <TabAtkins> | Even the word is ugnly. |
| 20:26 | <Ms2ger> | Thank you, TabAtkins |
| 20:26 | <SamB> | the important advantages can basically be summarized as "not being fugly" and "having a real module system" |
| 20:27 | <Ms2ger> | Modules are pretty big |
| 20:27 | <SamB> | and C++ code wants to recompile at the drop of a hat |
| 20:28 | <SamB> | C doesn't have so much trouble there because C actually supports encapsulation |
| 20:34 | SamB | idly wonders if Hixie uses the IDE or Emacs to edit his Object Pascal |
| 20:34 | <Hixie> | emacs |
| 20:34 | <Hixie> | i couldn't get the ide to work |
| 20:35 | <Hixie> | (didn't try very hard, mind you) |
| 20:35 | <Hixie> | SamB: pascal as a language is designed to compile really freaking fast, especially when you only change one file (unit) |
| 20:36 | <SamB> | having interface files tends to help with that :-) |
| 20:36 | <Hixie> | SamB: but yeah, the freepascal compiler's optimisations aren't the world's leading optimisations |
| 20:36 | <SamB> | at least I know I've seen GHC tell me "oh whoops don't need to recompile that module" lots of times |
| 20:36 | <SamB> | Hixie: it seems kind of traditional ;-) |
| 20:37 | <SamB> | I mean have you seen the code that TP used to emit? |
| 20:37 | <SamB> | granted, I guess part of that is that the registers are even *less* flexible in 16-bit mode |
| 20:40 | <Hixie> | at the time i used TP, i wasn't particularly knowledgable about optimisations |
| 20:40 | <Hixie> | i mean, when i was a kid i thought that short-circuit boolean evaluation was Hot Stuff... |
| 20:43 | <Hixie> | hm, oops. |
| 20:43 | <Hixie> | i didn't notice that "push onto the list of active formatting elements" was non-trivial. |
| 20:44 | <SamB> | yeah, well, see, I was trying to decompile ZZT by hand |
| 20:45 | <SamB> | using a slightly different version of TP/BP |
| 20:45 | <SamB> | in modern times |
| 20:45 | <caitp> | annevk, firefox and chrome behave differently WRT the same-origin policy when talking to file uris (with the default security.fileuri.origin_policy) --- which behaviour is actually correct? it seems to me that gecko is doing the wrong thing here, but it's not super clear |
| 20:45 | <annevk> | TabAtkins: what if you paint on a <canvas> from another document? |
| 20:45 | <SamB> | but this was before I learned how restricted the registers are in 16-bit mode |
| 20:46 | <TabAtkins> | annevk: I don't understand what you mean. |
| 20:46 | <annevk> | caitp: file URLs are not standardized |
| 20:46 | <caitp> | hm |
| 20:46 | <annevk> | TabAtkins: from document create another document, create an element in that document that's named canvas |
| 20:46 | <SamB> | also, it's hard to figure out how to deal with file:// URLs and same-origin stuff |
| 20:47 | <SamB> | because there's no obvious "origin" boundaries in a filesystem |
| 20:47 | <TabAtkins> | annevk: I'd suppose that the "context" for the drawing op is the document that is executing the script? |
| 20:47 | <TabAtkins> | (That's underdefined right now.) |
| 20:47 | <caitp> | I think that's why in blink-land it's always a cross-origin request, and is only allowed depending on how the request is made |
| 20:48 | <annevk> | TabAtkins: yeah not sure, would have to test |
| 20:48 | <SamB> | you sure don't want to let things set their origin to "file:///" (if that means "/" in your browser on your OS) |
| 20:48 | <annevk> | origin is not a string people |
| 20:48 | <SamB> | yeah, yeah, yeah |
| 20:48 | <caitp> | you know what he means though =) |
| 20:49 | <annevk> | in any event, I'm not sure standardizing file is all that crucial |
| 20:49 | <SamB> | and the equivalent of "C:\\" is hardly better |
| 20:49 | <annevk> | making sure http to file fails is important, and Mixed Content takes care of that |
| 20:49 | <annevk> | and getting parsing of URLs starting with file: is somewhat important, though getting people to agree on that is harder |
| 20:50 | <SamB> | it would be nice if some browser would come along with a good way to set up origins though |
| 20:50 | <SamB> | for file:// |
| 20:50 | <annevk> | why, file != web, it's just legacy support |
| 20:50 | <SamB> | maybe a file you could plop down that would say "you can count this as an origin"? |
| 20:50 | <annevk> | like computers supporting floppy drives |
| 20:51 | <annevk> | anyway, nn |
| 20:51 | <SamB> | annevk: it'd simplify things for locally-installed HTML documentation |
| 20:51 | <SamB> | say, if you built some racket docs locally |
| 20:52 | <caitp> | but why would you want to do that when you could push the docs to drive.google.com or whatever apple's thing is called |
| 20:54 | <SamB> | caitp: easier to just turn off the damn protection ... |
| 20:55 | <caitp> | it's not a serious response =) but I guess remote storage is one reason why it's less of a thing |
| 20:56 | <caitp> | or could be, at any rate. |
| 21:36 | <SamB> | I don't suppose I can get some decent line-wrap markers to go with my "white-space: pre-wrap"? |
| 21:36 | <TabAtkins> | Nope. |
| 21:36 | <TabAtkins> | Not without JS, that is. |
| 21:37 | <Domenic> | blink-dev O_O |
| 21:41 | <SamB> | so emacs can do it for probably the last century, and browsers *still* can't do it? |
| 21:44 | <TabAtkins> | Domenic: Hahaha, wtf are those people doing. |
| 22:04 | <hober> | TabAtkins: s/wtf/wtaf/ |
| 22:14 | <TabAtkins> | hober: Indeed. |
| 22:16 | <SamB> | hmm, er, I will certainly not want hyphenation ... |
| 23:04 | <Hixie> | figures that i would fail on the very first test of tricky01.dat... |
| 23:04 | <Hixie> | with an internal error deep in the guts of my code, not even in the parser code... |
| 23:40 | SamB | mutters something about "display: segment-break;" ... |