| 00:01 | <jgraham> | Whilst I don't doubt that browsers could do better in many situations, I still maintain that complaining on the basis of some notional idea that web-pages are generally simple things that should never use much memory doesn't make any sense |
| 00:03 | <zewt> | running out of memory because of a browser is very new; never had anything close to this problem before maybe a year ago |
| 00:13 | <caitp-> | safari may be slow, but it does seem to do a pretty good job of keeping memory in check |
| 01:04 | <TabAtkins> | caitp-: Re "to pilgrim", https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/vsNKAtkRIpIJ |
| 02:29 | <hgl> | TabAtkins, sorry for the late reply. if advanced transition is overthinking, does it mean the spec isn't interested in provide a solution for a problem like http://jsbin.com/layuhadiku/1/edit?html,css,output ? |
| 02:47 | <hgl> | a quick question: when the spec says node.append(nodes), does it mean node.append(...nodes) or nodes is just a regular array? |
| 02:49 | <hgl> | nm, IDL covered it. |
| 04:50 | <MikeSmith> | roc: has ruby support landed already under a flag? |
| 04:50 | <MikeSmith> | in gecko I mean |
| 04:51 | <MikeSmith> | hmm yeah, I see dbaron's comment at https://bugzilla.mozilla.org/show_bug.cgi?id=256274#c204 |
| 04:51 | <MikeSmith> | layout.css.ruby.enabled I guess |
| 04:52 | <dbaron> | MikeSmith, Xidorn has been working on it lately |
| 04:52 | <MikeSmith> | oh hey dbaron |
| 04:52 | <MikeSmith> | cool, thanks for the info |
| 04:52 | <dbaron> | MikeSmith, we were just quibbling over getting the UA stylesheet bits landed today |
| 04:52 | <dbaron> | MikeSmith, so that might land within a few days, which would make the pref more useful, even though it's still in progress |
| 04:52 | <MikeSmith> | dbaron: very nice |
| 13:26 | <rubys> | annevk: you around? |
| 13:53 | <rubys> | annevk: when you get back, I'd be interested in any thoughts you may have on https://www.w3.org/Bugs/Public/show_bug.cgi?id=27687 |
| 13:53 | <rubys> | annevk: I |
| 13:53 | <rubys> | ... 'm in favor; and since there is clearly no urgency, I'd be inclined to only implement it in the rewritten parser |
| 13:56 | <annevk> | rubys: you mean making "http://s/:test"; non-conforming? And "http://s/ test "? |
| 13:56 | <rubys> | yes to the first. the second is " http://example.com/ " |
| 13:57 | <rubys> | more background: http://intertwingly.net/tmp/urlvsuri.html |
| 13:58 | <annevk> | ":" is not excluded from path segments per the specification |
| 13:58 | <rubys> | "the specification"? Which one (URL or RFC 3986)? |
| 13:58 | <annevk> | URL |
| 13:59 | <rubys> | I'm not suggesting changing the output of parse, simply indicating a conformance error. |
| 13:59 | <annevk> | That would also require changing the definition of path segments |
| 14:00 | <annevk> | And looking at https://tools.ietf.org/html/rfc3986#section-3.3 URIs can mostly contain a colon there just fine |
| 14:01 | <rubys> | re: dfn of path segments: I don't follow. Adding "if c is ':' then parse error" to https://url.spec.whatwg.org/#relative-path-start-state |
| 14:01 | <annevk> | That would make the parser inconsistent with how path segments are defined |
| 14:02 | <rubys> | ok, lets back up. First: segment-nz-nc explicitly excludes colons. |
| 14:02 | <rubys> | this is referenced by path-noscheme |
| 14:04 | <rubys> | Another way to address this would be to fix: https://specs.webplatform.org/url/webspecs/develop/#relative-url |
| 14:04 | <annevk> | Yeah, that's for a case like <a href="s:test"> as due to the colon it can no longer be a relative reference |
| 14:04 | <rubys> | no, it explicitly is only the first character |
| 14:05 | <annevk> | no |
| 14:05 | <annevk> | 'non-zero-length segment without any colon ":"' |
| 14:06 | <rubys> | ok |
| 14:06 | <rubys> | path-noscheme = segment-nz-nc *( "/" segment ) |
| 14:06 | <rubys> | so this bizarre rule only applies to the first segment |
| 14:06 | <annevk> | yes, because of what I just said |
| 14:06 | <annevk> | it's for relative references only |
| 14:06 | <annevk> | so you can disambiguate those from URIs |
| 14:08 | <rubys> | going back to https://specs.webplatform.org/url/webspecs/develop/#relative-url, this check could be added to the last path. |
| 14:09 | <rubys> | all other cases have either a colon or a slash before the path |
| 14:10 | <annevk> | if you have this top down matching that seems redundant |
| 14:11 | <rubys> | it clearly isn't, as ":a" doesn't produce a conformance error. |
| 14:13 | <rubys> | I guess another way to fix this would be to allow scheme to return zero length strings, but produce a conformance error along the way. See https://specs.webplatform.org/url/webspecs/develop/#scheme |
| 14:15 | <rubys> | @: would, however, be considered a conforming relative URL but not a valid URI |
| 14:18 | <gavinc> | rubys: small confusion "urltestdata.txt has the following tests" ... which tests? |
| 14:23 | <rubys> | gavinc: here is urltestdata.txt: https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt |
| 14:23 | <gavinc> | So ALL of those? |
| 14:24 | <rubys> | gavinc: I'm confused about what you are confused about. :-) |
| 14:24 | <rubys> | Here's the results of the tests: https://url.spec.whatwg.org/interop/test-results/ |
| 14:25 | <rubys> | looking at those results, there are some conforming URLs that are not valid URIs. I think that should be fixed. |
| 14:25 | <rubys> | looking deeper, I came up with: http://intertwingly.net/tmp/urlvsuri.html |
| 14:26 | <gavinc> | Okay, sorry, the bug just didn't say which of the tests in urltestdata.txt were being talked about |
| 14:27 | <rubys> | gavinc: ah. that is indeed confusing |
| 14:27 | <rubys> | I meant to enumerate them |
| 14:31 | <rubys> | comment added to the bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27687#c1 |
| 14:32 | <gavinc> | annevk's solution doesn't seem to cover " foo.com " from that list nor 100% whitespace like " \t" ? |
| 14:33 | <rubys> | we didn't discuss that. I'm proposing adding a check to https://specs.webplatform.org/url/webspecs/develop/#concept-basic-url-parser |
| 14:36 | <gavinc> | mm, so by that wouldn't " foo.com " just become "foo.com" relative to any currently set base? |
| 14:36 | <gavinc> | and " \t" become the same as an empty "", and thus again resolve relative to the current base? |
| 14:37 | <rubys> | gavinc: yes. want to play with a few tests? Try: https://url.spec.whatwg.org/reference-implementation/liveview2.html#about%3A |
| 14:37 | <rubys> | also, some tests have already been defined with test results captured for a variety of user agents: https://url.spec.whatwg.org/interop/test-results/ |
| 14:39 | gavinc | reads more |
| 14:42 | <gavinc> | "A parse error if leading/trailing white space is present in" seems a bit, mmm, over zealous? Given that none of the implementations today consider " foo.com " to be a parse error |
| 14:43 | <rubys> | a conformance error. See https://specs.webplatform.org/url/webspecs/develop/#url-writing |
| 14:47 | <gavinc> | ah, so not parse exception, so go ahead and keep parsing |
| 17:13 | <rubys> | *sigh* http://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0087.html |