| 00:01 | <Hixie> | success! my pipline now outputs the same as anolis |
| 00:01 | <Hixie> | ...for the first line of the file, anyway |
| 01:23 | <MikeSmith> | Hixie: validator.nu is fast enough that it can check the entire HTML spec in less than 3 seconds |
| 01:24 | <MikeSmith> | Hixie: the part of that time that's taken up by parsing is milliseconds |
| 02:19 | <Manishearth> | annevk: around? |
| 02:50 | <Hixie> | gsnedders: hey do you know what order anolis uses for attributes when serialising? |
| 02:50 | <Hixie> | MikeSmith: really? |
| 02:50 | <Hixie> | MikeSmith: it always seems to take quite a lot longer, to me... |
| 02:51 | <Hixie> | MikeSmith: hm, no, i guess you're right |
| 02:52 | <Hixie> | MikeSmith: that's pretty impressive |
| 02:52 | <MikeSmith> | the power of hsivonen |
| 02:52 | <Hixie> | of course this is a different machine |
| 02:52 | <Hixie> | so i dunno how it compares |
| 02:52 | <MikeSmith> | true |
| 02:54 | <Hixie> | what tricks does the parser use? |
| 02:54 | <Hixie> | i mean, things like interning the strings to do string comparisons, dispatch tables, etc |
| 02:54 | <MikeSmith> | that you would need to ask Henri about |
| 02:55 | <MikeSmith> | I'm really only familiar with the parts of the parser code that I've patched, which isn't very many parts, and mostly trivial |
| 02:56 | <MikeSmith> | though I'm not reminded that I'm waiting on Henri to make a decision about handling of un-ambiguous ampersands in the parser to bring it into conformance with the HTML spec |
| 02:57 | <Hixie> | i don't understand the whitespace stripping that anolis does |
| 02:57 | <Hixie> | actually i guess it's probably libhtml or whatever parser anolis uses |
| 02:57 | <MikeSmith> | (the validator error messages about, e.g., the ampersand in "http://x?foo&bar"; being invalid are actually generated by the parser, which is an error-reporting implementation) |
| 02:58 | <MikeSmith> | Hixie: bingo |
| 02:58 | <Hixie> | still, i don't understand it |
| 02:59 | <MikeSmith> | in my experience there are a lot of WTFs in the results from the 3rd-party library code that anolis and the splitter use |
| 03:00 | <Hixie> | yeah but if i don't reproduce those wtfs precisely, it's gonna be a pain to check the results :-) |
| 03:00 | <MikeSmith> | ah |
| 03:01 | <Manishearth> | Hey, I'm a bit unclear about the xhr spec, anyone who can help with that? |
| 03:02 | <Manishearth> | Specifically, http://xhr.spec.whatwg.org/#the-send()-method step 13 |
| 03:02 | <MikeSmith> | Hixie: I dealt with them in the past just be doing some post-processing. but I never noticed weirdness in teh WS handling |
| 03:02 | <Manishearth> | The handling for synchronous requests is not totally clear to me since it seems to omit some important steps |
| 03:03 | <MikeSmith> | Manishearth: annevk would be the one to ask but pretty sure he's sleeping at these hours |
| 03:03 | <Manishearth> | yeah |
| 03:03 | <Manishearth> | Ms2ger isn't around either, usually I ask him :) |
| 03:04 | <MikeSmith> | Manishearth: I wonder why you want to handle synchronous requests |
| 03:05 | <Manishearth> | MikeSmith: because I'm implementing XHR, and web-platform-tests wants them |
| 03:05 | <Manishearth> | :) |
| 03:06 | <Manishearth> | wpt uses sync fetch often to get better workflow. I agree that sync fetch is a rather bad way of doing things on the web |
| 03:07 | <MikeSmith> | indeed |
| 03:07 | <MikeSmith> | I didn't know wpt was doing that |
| 03:08 | <Manishearth> | The one that's breaking for me right now is https://github.com/w3c/web-platform-tests/blob/master/XMLHttpRequest/abort-after-send.htm |
| 03:08 | MikeSmith | looks |
| 03:08 | <Manishearth> | because I'm not setting the readystate properly |
| 03:08 | <Manishearth> | When the spec says "If req's synchronous flag is set, pass the return value, synchronously, to process response end-of-file below." |
| 03:09 | <Manishearth> | I'm not sure if I'm suposed to skip the other "process" steps. I'm doing the steps, storing the data, but not sure if I should be changing ready state and firing events |
| 03:09 | <Manishearth> | readystatechange/onprogress doesn't make much sense for sync anyway |
| 03:09 | <MikeSmith> | right |
| 03:10 | <Manishearth> | So for sync should the only effect on the XHR object be the changing of the ready state to Done when it finishes? |
| 03:11 | <Manishearth> | or should I be changing the ready state each step for sync, but not firing the event? |
| 03:13 | MikeSmith | tries to think of who else might be around right now who's implemented XHR |
| 03:13 | <MikeSmith> | ah wait you're the one who's working on the XHR ipmlementation for servo? |
| 03:14 | MikeSmith | scratches off his "ask that guy who's working on the XHR implementation in servo" suggestion |
| 03:15 | <Manishearth> | pahaha |
| 03:15 | <MikeSmith> | smaug's not awake yet either |
| 03:18 | <Manishearth> | np, I'll wait till Ms2ger comes back then. I have one way of fixing the immediate issue, but I think it's best if I'm clear about that part of the spec |
| 05:29 | <zcorpan> | Hixie: maybe you can run anolis with html5lib instead for comparison of the result? |
| 06:33 | <annevk> | Manishearth: around now |
| 06:34 | <annevk> | Manishearth: yeah, even for synchronous you should dispatch readystatechange et al in the end |
| 06:35 | <annevk> | Manishearth: but yeah, that could be done better |
| 06:38 | <jamesr_> | Manishearth: sync XHR is one of those fun APIs that runs javascript reentrantly |
| 06:38 | <jamesr_> | the blink implementation is pretty straightforward, i can check things if you'd like |
| 06:38 | <annevk> | jamesr_: not per spec |
| 06:38 | <jamesr_> | annevk: oh? in webkit/blink the rsc events fire 'under' the send() call, i believe |
| 06:38 | jamesr_ | cooks up test |
| 06:39 | <annevk> | jamesr_: per spec there's only a final set of events just before send() returns |
| 06:39 | <annevk> | jamesr_: but since the events are sync too, that's not re-entrant |
| 06:39 | <jamesr_> | the event handlers run before control returns to whoever calls send(), no? |
| 06:40 | <annevk> | jamesr_: sure |
| 06:40 | <annevk> | jamesr_: I guess that's a bit re-entrant, but no more than some custom function I have invoking dispatchEvent() |
| 06:40 | <jamesr_> | ok. i guess it's a terminology difference, then. to me that's reentrant |
| 06:40 | <jamesr_> | right, since they are event handlers |
| 06:40 | <annevk> | jamesr_: fair, I was thinking nested event loop |
| 06:41 | <annevk> | jamesr_: which is what Gecko has at the moment and is definitely not supported by the spec |
| 06:41 | <jamesr_> | nah. we don't run anything else while the xhr is out |
| 06:41 | <jamesr_> | in chromium, the entire process's blink thread is locked |
| 06:50 | <annevk> | So six months after the purported deadline of ES6, class design is being reconsidered |
| 06:51 | <annevk> | When I said a while back it would take at least a year for people to get around to do proper subclassing everywhere, people got angry |
| 06:54 | <Manishearth> | annevk: lunchtime for me, will get back to you on this. Thanks! |
| 06:58 | <jamesr_> | is servo attempting the storage mutex stuff? or skipping it? |
| 07:05 | annevk | doesn't know |
| 07:10 | <krit> | annevk: morning |
| 07:10 | <krit> | annevk: I added a question to the pad on the first algorithm |
| 07:11 | <krit> | annevk: if the associated document is document.svg would url(document.svg#frag) be treated as element reference? |
| 07:12 | <krit> | annevk: ..assuming the specified value is on an external CSS |
| 07:12 | <krit> | annevk: it certainly can’t be used as image since it would reference itself |
| 07:13 | <annevk> | krit: why can't it be fetched and treated as image? |
| 07:13 | <annevk> | krit: more important, what do implementations do now? |
| 07:14 | <krit> | annevk: depends on the property… need to check an example with image… one moment |
| 07:15 | <annevk> | I'm again surprised these questions haven't come up before, but I guess it's good we are addressing them now |
| 07:18 | <krit> | annevk: there are no properties that reference images in SVG |
| 07:19 | <krit> | annevk: With the exception of ‘cursor' |
| 07:19 | <annevk> | krit: okay, but is it treated as an external reference today or an internal? |
| 07:20 | <annevk> | krit: if url(style.css#frag) is internal, surely that must be external |
| 07:20 | <krit> | annevk: that depends on the property. There is no implemented property that can be either of both today |
| 07:20 | <annevk> | krit: not even in Gecko? |
| 07:21 | <krit> | annevk: not even in Gecko…. however, give me a couple of minutes and I reproduce it with fill and cursor |
| 07:22 | <annevk> | krit: okay, but we should still be able to answer the question, if url(style.css#frag) is internal, then url(document.svg#frag) is either external or should not work |
| 07:22 | <annevk> | krit: can we at least confirm that much? |
| 07:23 | <krit> | annevk: ok, self referencing with cursor doesn’t work |
| 07:23 | <annevk> | krit: are you testing in a browser that supports SVG for cursors? |
| 07:23 | <krit> | annevk: needs checking in FF as well. I already told you what Blink and WebKit would do |
| 07:23 | <krit> | annevk: I would need to search a browser that doesn't |
| 07:24 | <krit> | annevk: of course it supports SVG |
| 07:24 | <annevk> | krit: does it start working if the style sheet is then associated with a different document? |
| 07:25 | <annevk> | Are the tests online? |
| 07:26 | <krit> | annevk: no, can paste them |
| 07:26 | <krit> | https://www.irccloud.com/pastebin/vf3hQKYS |
| 07:27 | <krit> | style.css#grad doesn’t work, self.html#grad does in Firefox |
| 07:27 | <annevk> | and #grad does too? |
| 07:28 | <krit> | annevk: yes |
| 07:28 | <annevk> | :-( |
| 07:28 | <krit> | annevk: same behavior in Blink WebKit (to my surprise) |
| 07:29 | <krit> | annevk: so the algorithm does not what FF, Chrome and Safari do today |
| 07:32 | <annevk> | krit: in http://dump.testsuite.org/svg/url-parsing.html with #grad it does not work in Firefox |
| 07:33 | <krit> | annevk: it does |
| 07:33 | <krit> | annevk: it is red |
| 07:33 | <annevk> | krit: refresh |
| 07:34 | <annevk> | In Nightly there is no red |
| 07:34 | <annevk> | Only if I change it to url-parsing.html#grad |
| 07:34 | <annevk> | That means Firefox actually does sensible URL parsing here |
| 07:35 | <krit> | annevk: hm, interesting… it does work locally |
| 07:35 | <krit> | no it doesn't |
| 07:36 | <annevk> | Yay Firefox for sanity |
| 07:37 | <krit> | annevk: It does work in Safari, Chrome and IE |
| 07:38 | <annevk> | krit: I recommend we get them to fix this bug |
| 07:38 | <krit> | ed: willing to change the behavior on Blink —^ |
| 07:38 | <krit> | *in |
| 07:39 | <annevk> | not sure ed is in this channel |
| 07:39 | <krit> | argh, wait |
| 07:39 | <krit> | he is offline :( |
| 07:39 | <annevk> | ah okay |
| 07:39 | <krit> | I know why this happens in WebKit and Blink and the implementation needs to be fixed anyway |
| 07:40 | <annevk> | Yeah, you told me they parse the URL and then grab the fragment not doing any comparisons |
| 07:40 | <krit> | annevk: I wouldn’t mind changing the behavior in WebKit when I get to implement it |
| 07:40 | <annevk> | Very happy Firefox didn't fuck it up |
| 07:40 | <krit> | annevk: this is not fully true anymore…. style.css#frag doesn’t work either |
| 07:41 | <annevk> | Fair, so they must special case # at the start somehow |
| 07:42 | <krit> | annevk: yes, I assume we check the baseURL at the beginning… later we just care about the fragment identifier |
| 07:42 | <krit> | annevk: I am willing to change that |
| 07:43 | <krit> | annevk: so /document/ is still not correct in the algorithm… it must always check associated document URL |
| 07:43 | <krit> | annevk: which can be /document/ but doesn’t need to |
| 07:43 | <annevk> | krit: yeah, we should probably split CSS and element handling |
| 07:43 | <annevk> | krit: otherwise this gets too confusing |
| 07:44 | <krit> | annevk: yes, we would split it anyway and the behavior needs to go to CSS directly |
| 07:44 | <krit> | annevk: as a general behavior for future usage of url() |
| 07:46 | <annevk> | krit: yeah, my plan is to write an email to www-style about this and work with TabAtkins to make it happen |
| 07:47 | <annevk> | krit: but before I do that I think it would be good for us to write the actual algorithms to make sure we're not missing anything |
| 07:48 | <krit> | annevk: k. |
| 07:48 | <krit> | annevk: Btw. with stacked SVGs, fragment sniffing is still possible cross domain |
| 07:48 | <krit> | annevk: the one thing the abarth thought would be a problem |
| 07:49 | <krit> | annevk: not sure if it really is a problem since you can mostly do it with JS today |
| 07:49 | <krit> | annevk: or even manually |
| 07:50 | <krit> | annevk: just clip-path: url() is still a problem since it changes geometry… but this would require sensitive data within the clip-path |
| 07:51 | <krit> | ...so encoding a password in the path data of clip-path |
| 07:52 | <krit> | which we of course can not prevent someone from doing…. but it is extremely unlikely as well |
| 07:57 | <annevk> | how can you do fragment sniffing using :target? |
| 07:58 | <krit> | annevk: no, abarth use case was the active involvement of the user |
| 07:58 | <krit> | annevk: with :target you can make certain element visible or invisible |
| 07:58 | <annevk> | but you don't know anything about the remote file |
| 07:58 | <krit> | annevk: not without the help of the user |
| 07:59 | <krit> | annevk: the link from abarth https://news.ycombinator.com/item?id=7855168 |
| 07:59 | <annevk> | I don't understand, the remote file would have to use :target |
| 07:59 | <krit> | annevk: yes, that is true |
| 07:59 | <annevk> | I don't really follow the attack scenario |
| 08:00 | <annevk> | Anyway, back in a bit |
| 08:44 | <Manishearth> | annevk: So do you think that in the sync case, all readystatechange events should be fired? |
| 08:45 | <Manishearth> | because thir handlers will only be executed after the sync finishes |
| 08:45 | <Manishearth> | or should the *last* one be the only one to fire? |
| 08:49 | <annevk> | krit: I updated the algorithms |
| 08:49 | <annevk> | krit: they now work for either style sheets or documents |
| 08:49 | <krit> | looking |
| 08:49 | <annevk> | Manishearth: only the last |
| 08:50 | <Manishearth> | annevk: Alrighty. Same answer for progress events? |
| 08:50 | <Manishearth> | (only fire the last triplet of events) |
| 08:51 | <annevk> | Manishearth: the idea is that sync would invoke "To process response end-of-file for response, run these substeps: " |
| 08:51 | <annevk> | Manishearth: there's a bug now though that state would not be LOADING |
| 08:51 | <Manishearth> | annevk: exactly :) |
| 08:51 | <Manishearth> | that's how I found it out |
| 08:52 | <annevk> | Manishearth: yeah I should rewrite this a bit to make it more clear what the synchronous handling is |
| 08:52 | <Manishearth> | My ready state in sync wasn't changing because I had implemented the spec, and I thought I had misinterpreted the "If req's synchronous flag is set, pass the return value, synchronously, to process response end-of-file below." |
| 08:54 | <annevk> | Manishearth: how would you like to be acknowledged? |
| 08:54 | <annevk> | Manish Goregaokar? |
| 08:54 | <Manishearth> | annevk: I think a simple `If state is LOADING or the sync flag is set, run these subsubsteps:` would work |
| 08:54 | <Manishearth> | annevk: yeah |
| 08:54 | <Manishearth> | thanks |
| 08:54 | <krit> | annevk: to confirm, for #get-svg-element it is not possible for authors to specify a dataURL or blob… in general it seems just possible for fetching images |
| 08:54 | <krit> | annevk: note: no idea if dataURL or blog would make sense |
| 08:54 | <krit> | hee |
| 08:54 | <krit> | here |
| 08:55 | <annevk> | why would it not be possible? |
| 08:56 | <krit> | annevk: in your algorithm it would run into fetch, no? |
| 08:56 | <annevk> | krit: yes, and Fetch handles data and blob URLs |
| 08:56 | <krit> | annevk: fetch is not permitted if /internal only flag/ is true |
| 08:57 | <krit> | annevk: that means dataURL and blob are not allowed for SVG as image |
| 08:57 | <krit> | image/svg+xml |
| 08:57 | <annevk> | krit: no it doesn't |
| 08:57 | <annevk> | krit: the internal only flag is for cases that don't handle external references |
| 08:57 | <annevk> | krit: it's not for SVG as image |
| 08:57 | <krit> | ok, got it |
| 08:58 | <annevk> | lets rename that one to local only flag |
| 08:58 | <krit> | annevk: #get-local-svg-element seems to allow style.css#frag |
| 08:58 | <annevk> | no it doesn't |
| 08:59 | <annevk> | /baseURL/ would be the style sheet's URL and /document/ would be the style sheet's associated document |
| 08:59 | <krit> | annevk: oh, because we do not look at external CSS anymore? |
| 08:59 | <krit> | ahh |
| 08:59 | <krit> | ok |
| 08:59 | <krit> | annevk: is that defined that way in Fetch alread? |
| 08:59 | <krit> | annevk: or does the algorithm need to do that |
| 09:00 | <annevk> | Is what defined? |
| 09:00 | <annevk> | Manishearth: it might take me a while to get to this, I'd like to fix it more properly than that |
| 09:00 | <Manishearth> | annevk: Ah, I see. No problem |
| 09:00 | <krit> | annevk: this “/document/ would be the style sheet's associated document" |
| 09:00 | <Manishearth> | We might have to change the wording for the error handling too |
| 09:01 | <annevk> | krit: no, that all needs to be handled by SVG and CSS |
| 09:01 | <annevk> | krit: Fetch only deals with getting a bag of bits out of a URL |
| 09:01 | <annevk> | krit: and all the hassle that comes with that, it doesn't have magic built in |
| 09:02 | <krit> | no magic, k :D |
| 09:02 | <annevk> | krit: what Fetch handles is indicated with [FETCH] |
| 09:02 | <krit> | thanks |
| 09:03 | <annevk> | everything else, including the line indicated with [FETCH] (so everything really) needs to be in SVG / CSS |
| 09:05 | <annevk> | krit: actually, maybe these algorithms should take a parsedURL and a document, that seems better |
| 09:06 | <krit> | annevk: fetching an SVG element: “...MIME type is not image/svg+xml” what about application/xml |
| 09:06 | <krit> | annevk: SVG can still be an XML documen |
| 09:06 | <krit> | t |
| 09:06 | <krit> | annevk: or, inline SVG, where the fetched SVG element is in an HTML document |
| 09:06 | <annevk> | I thought that was outlawed |
| 09:07 | <krit> | annevk: The CSS example that you uploaded used it. ok was local, but I think FF supports it for other HTML documents as well |
| 09:08 | <krit> | annevk: only Firefox would support it… |
| 09:08 | <annevk> | local is completely different |
| 09:08 | <annevk> | krit: depends, how does <use> work? |
| 09:09 | <krit> | annevk: uses the processing algorithm from SVG that you referenced yesterday |
| 09:10 | <krit> | annevk: not restricted to mime type it seems |
| 09:10 | <krit> | annevk: http://www.w3.org/TR/SVG/linking.html#processingIRI |
| 09:11 | <annevk> | krit: what about implementations? |
| 09:11 | <krit> | annevk: again, just Firefox would have implemented it… maybe Presto |
| 09:11 | <krit> | annevk: creating an example |
| 09:12 | <annevk> | krit: I thought ed demonstrated external <use> support in Blink? |
| 09:12 | <krit> | oh right… was about to check for CSS |
| 09:17 | <krit> | annevk: for CSS I don’t even get it to work with paint server in another SVG file right now... |
| 09:17 | <krit> | annevk: same for paint server in an SVG |
| 09:17 | <krit> | s/SVG/HTML/ |
| 09:19 | <krit> | annevk: ok, paint server in SVG document works… in HTML doesn't |
| 09:19 | <krit> | annevk: for CSS on Firefox |
| 09:19 | <annevk> | krit: so I thought the idea was that external SVG elements would follow the SVG as image path |
| 09:19 | <annevk> | krit: which means only image/svg+xml |
| 09:20 | <krit> | annevk: the same mode… |
| 09:20 | <krit> | annevk: same mode as image/svg+xml |
| 09:20 | <krit> | annevk: but let me check <use> first |
| 09:23 | <krit> | annevk: example with <use> to other <svg> https://dl.dropboxusercontent.com/u/39760138/self/selfReference.html |
| 09:24 | <krit> | annevk: seems not to work in FF, but in Safar/Chrome |
| 09:25 | <krit> | annevk: https://dl.dropboxusercontent.com/u/39760138/self/selfReference2.html <use> element reference to HTML |
| 09:25 | <krit> | annevk: doesn’t work anywhere |
| 09:27 | <krit> | annevk: ok, had a styling issue… first example works in FF now |
| 09:27 | <krit> | annevk: 2nd seems to run in loops |
| 09:28 | <krit> | annevk: FF doesn’t stop loading |
| 09:28 | <krit> | annevk: possibly a bug in FF |
| 09:29 | <krit> | annevk: https://dl.dropboxusercontent.com/u/39760138/self/selfReference3.html in this case I have a other.xml that I reference it works… but probably because browsers don’t always trust the mime type |
| 09:30 | <krit> | annevk: Firefox loads it with MIME type application/xml |
| 09:30 | <krit> | annevk: other.xml |
| 09:31 | <annevk> | krit: okay, that does indicate the MIME type check is different for external references from images |
| 09:31 | <krit> | so image/svg+xml and application/xml should be possible |
| 09:31 | <annevk> | which seems like a good reason keep external references and images distinct |
| 09:31 | <annevk> | and potentially apply different fetch modes to them |
| 09:37 | <roc> | this again! |
| 09:38 | <roc> | I thought we had previously converged on a consensus to make external references and images use the same fetch model |
| 09:40 | <annevk> | hey roc |
| 09:40 | <annevk> | roc: it seems that is impossible given that we support things like image.svg#test |
| 09:41 | <annevk> | roc: http://dahlström.net/svg/structure/svgstack-usage.html |
| 09:41 | <annevk> | roc: we're trying to figure out SVG/CSS fetching bits a bit more formally here https://etherpad.mozilla.org/fixing-svg-processing |
| 09:50 | <roc> | I thought the resolution was to make everything use the image model |
| 10:01 | <annevk> | roc: given mask:url(someurl#test) |
| 10:01 | <annevk> | roc: how do we know whether that's an image with #test or an mask identified by #test? |
| 10:02 | <roc> | do an image load |
| 10:02 | <roc> | if #test is a <mask> element, treat it as a mask |
| 10:03 | <roc> | do some kind of same-origin check |
| 10:03 | <roc> | We had this worked out somewhere |
| 10:04 | <annevk> | Manishearth: should be more clear now |
| 10:04 | <annevk> | roc: yes, except http://dahlström.net/svg/structure/svgstack-usage.html seems to kill that solution |
| 10:05 | <annevk> | roc: and apparently we allow more than SVG images for these loads (e.g. application/xml resources) |
| 10:05 | <roc> | no it doesn't. None of the referenced elements there are <mask>s |
| 10:05 | <roc> | or <pattern>s or gradients |
| 10:06 | <annevk> | roc: fair |
| 10:06 | <annevk> | roc: what about supporting more than image/svg+xml? |
| 10:08 | <annevk> | roc: I think the other thing that changed is that we learned image fetching is really rather involved: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24055 |
| 10:08 | <roc> | I don't think supporting application/xml is important |
| 10:08 | <roc> | servers are likely to map *.svg to image/svg+xml anyway |
| 10:08 | <annevk> | roc: which means that overloading it with external element references might be painful, but I guess we can deal |
| 10:09 | <annevk> | I'm happy to write out that solution |
| 10:09 | <roc> | I don't think we'd be overloading it. I assume the image fetch algorithm eventually can produce something with an SVG DOM |
| 10:09 | <annevk> | krit: ^ |
| 10:09 | <annevk> | roc: yeah fair, image fetch has a branch for image/svg+xml |
| 10:09 | <roc> | that is, I assume it can produce many results, at least some of which have an SVG DOM |
| 10:10 | <roc> | then we just need to be able to do some kind of same-origin check and get read-only access to the DOM |
| 10:11 | <annevk> | yeah, we'd parse with scripting disabled |
| 10:11 | <roc> | of course animations could be running in the DOM so it's a bit more complicated than that, but it should work |
| 10:11 | <annevk> | and then we need some kind of "safe render mode for SVG" that handles the rest |
| 10:11 | <annevk> | that disables fetching more resources |
| 10:12 | <roc> | yeah, we already have that implemented. I think SVG specced something like that or at least talked about it |
| 10:12 | <annevk> | only talk so far, we're trying to write down the basics now |
| 10:12 | <krit> | roc: the solution from annevk adds heuristics that would allow assumptions on the fetched resource before fetching it…. local element or image is that |
| 10:13 | <krit> | roc: that would be significant easier to implement in WebKit and Blink |
| 10:13 | <krit> | roc: without need to rewrite our CSS engine |
| 10:13 | <roc> | krit: you mean heuristics to guess whether it's an image load or an external resource load? |
| 10:13 | <roc> | I advocated that for a long time myself :-) |
| 10:13 | <krit> | roc: yes |
| 10:13 | <annevk> | krit: no |
| 10:13 | <annevk> | that algorithm only handles local references or images |
| 10:13 | <annevk> | not external references |
| 10:14 | <annevk> | if you want both you need the solution roc and I came up with a year ago |
| 10:14 | <krit> | annevk: of course since your algo. does not allow fetching for things that can get an element or image… so we check the baseURL to figure that part out |
| 10:14 | <krit> | annevk: my point |
| 10:14 | <roc> | I thought we could say url(...#foo) is an external resource load and too bad about SVG image stacks |
| 10:14 | <roc> | however |
| 10:14 | <krit> | annevk: I don’t want both |
| 10:14 | <annevk> | krit: yes but roc does |
| 10:14 | <roc> | I don't want that approach anymore |
| 10:14 | <roc> | now I think just using image fetch will be fine |
| 10:15 | <roc> | and simpler |
| 10:15 | <krit> | roc: would you be fine with no external paint server loads on url() function? |
| 10:15 | <krit> | roc: cool |
| 10:15 | <roc> | er |
| 10:15 | <annevk> | krit: you misunderstand roc |
| 10:15 | <krit> | maybe |
| 10:15 | <krit> | roc: say again please? |
| 10:15 | <roc> | I'm saying you can have external paint servers, it's just that the document is always loaded using the image fetch algorithm |
| 10:16 | <krit> | roc: yeah, that is what Anne and I discussed on monday |
| 10:16 | <annevk> | krit: if image fetch returns an SVG document and fragment points to a <mask> in it, it's a mask, otherwise an image, stuff like that |
| 10:16 | <roc> | so fill:url(foo.svg#bar) would load foo.svg as an image, and then if the 'bar' element is a paint server, it gets used as a paint server, otherwise it's treated as the foo.svg#bar image |
| 10:16 | <krit> | roc: again, would require to rewrite parts of WebKit and Blinks CSS engine |
| 10:17 | <krit> | roc: Blink doesn’t seem to be keen about external element fetches for url() either |
| 10:17 | <krit> | *as well |
| 10:17 | <roc> | I don't see what the problem is |
| 10:17 | <annevk> | krit: Blink is fine with it as long as the security check is there |
| 10:17 | <annevk> | abarth said as much the other day |
| 10:17 | <krit> | roc: no, abarth is |
| 10:17 | <roc> | Blink/Webkit don't currently support "external resource reference" loads, but they do support SVG image loads. Gecko supports both |
| 10:17 | <krit> | annevk: —^ |
| 10:18 | <krit> | roc: right, we don't |
| 10:18 | <roc> | I'm proposing we eliminate external resource reference loads and only use SVG image loads, which Webkit/Blink already have. This is a great proposal for those guys :-) |
| 10:18 | <krit> | roc: that is Annes solution |
| 10:18 | <krit> | roc: element references just in the current SVG document |
| 10:19 | <krit> | roc: no external element references |
| 10:19 | <annevk> | krit: no it's not |
| 10:19 | <annevk> | geez |
| 10:19 | <roc> | krit: I think you're confused but I don't know exactly how :-) |
| 10:19 | <krit> | annevk: #get-svg-element To get an SVG element given a /url/, a /document/, and an optional /internal only flag/: does exactly that |
| 10:20 | <annevk> | krit: no it doesn't support external SVG elements |
| 10:20 | <annevk> | krit: roc is proposing we do |
| 10:20 | <krit> | roc: fill: url(externDocument.svg#pattern) is not supported in WebKit and Blink… but in FF… do you want it to work or don’t you care? |
| 10:20 | <annevk> | krit: you apply the same fetch algorithm as for images, and then you do post processing to determine whether or not it's an image or an external ref |
| 10:21 | <roc> | what Anne said |
| 10:21 | <krit> | roc: too bad :( |
| 10:21 | <roc> | ? |
| 10:22 | <krit> | roc: I am not advocating for allowing external paint servers |
| 10:22 | <roc> | you mean you're against it? |
| 10:22 | <krit> | roc: so your opinion is not mine :) |
| 10:22 | <krit> | roc: even so I agree that it works in theory |
| 10:24 | <krit> | roc: don’t believe that the implementation efforts for fetching the resource and figuring out what it is are worth it in WebKit |
| 10:24 | <roc> | ok |
| 10:24 | <krit> | roc: simple cost to usage calculation |
| 10:24 | <roc> | that's a reasonable position |
| 10:25 | <annevk> | roc: would you apply the same restrictions on <use>? |
| 10:26 | <roc> | Given we already support external references in some form, the Gecko situation is a bit different and we might reach a different conclusion. |
| 10:27 | <krit> | annevk: <use> is a different code path for us. However, <pattern> and co. with xlink:href still don’t need to reference external elements IMO |
| 10:27 | <krit> | roc: yes, right now I am entirely speaking as implementer... |
| 10:28 | <krit> | …implementer for WebKit and Blink |
| 10:28 | <roc> | annevk: I would just say that <use> does an SVG image load and uses any element it can find. I don't think <use> is or will be specced to actually use an image. |
| 10:29 | <annevk> | roc: yeah, just wondering if it would be restricted to image/svg+xml as well, but that sounds good to me |
| 10:29 | <krit> | roc: so we could agree on the general "fetch as image” algorithm. It might be implemented in two stages in WebKit and Blink… 2nd stage being external element |
| 10:29 | <krit> | s |
| 10:29 | <krit> | roc: annevk: speaking for the CSS part of it |
| 10:30 | <roc> | annevk: yeah, I think there's no point in speccing a fetch algorithm just for <use> |
| 10:30 | <annevk> | roc: sgtm |
| 10:31 | <krit> | roc: What about <pattern>, <linearGradient>/ |
| 10:32 | <krit> | roc: both are not allowed to reference external elements in SVG… at least it could be interpreted that way |
| 10:32 | <krit> | roc: (SVG is not specific enought) |
| 10:32 | <krit> | roc: does Firefox allow referencing elements in other documents? <pattern xlink:href=“other.svg#patter”/> |
| 10:33 | <roc> | yeah I think so |
| 10:33 | <roc> | in Gecko we have nsReferencedElement which handles tracking dynamic ID changes etc |
| 10:33 | <roc> | it also handles external resource loads automatically |
| 10:33 | <krit> | roc: ok |
| 10:34 | <krit> | roc: I guess WebKit can generalize the code more to handle these elements as well |
| 10:35 | <krit> | annevk: ok, looks like one algorithm could be enough with a sub algorithm for image handling |
| 10:36 | <krit> | roc: another question mask: url(other.svg#maskDoesNotExist) would you interpret that as image with the new mask-image syntax? |
| 10:36 | <annevk> | krit: yeah, and we'd disable the image path for <use> and such |
| 10:36 | <annevk> | krit: yes that would be an image |
| 10:37 | <annevk> | krit: otherwise "stacked images" would not work |
| 10:37 | <krit> | annevk: exactly |
| 10:37 | <annevk> | we already covered that earlier |
| 10:38 | <krit> | annevk: also, ignore abarth external image fragment sniffing? |
| 10:38 | <krit> | annevk: (me doesn’t think it is a strong case anyway) |
| 10:39 | <annevk> | krit: well we could require CORS opt-in for the external ref case (and only make images work for opaque responses) |
| 10:39 | <annevk> | krit: depends a bit on security guys |
| 10:39 | <krit> | annevk: yes |
| 10:40 | <annevk> | I guess this requires some additional parameter to the algorithm to indicate what is expected |
| 10:41 | <krit> | annevk: we require that later anyway when url() gets CORS arguments, don’t we? |
| 10:41 | <annevk> | krit: if we don't require it now, CORS won't make a difference later |
| 10:41 | <krit> | annevk: so the algorithm can already pretend that this is an argument |
| 10:42 | <krit> | annevk: well what is the point of the parameters for url() anyway then |
| 10:42 | <annevk> | we need it at least for @import |
| 10:42 | <krit> | annevk: ok |
| 10:42 | <annevk> | we might need it for the external ref case, that depends on security analysis |
| 10:43 | <annevk> | it seems we need it for clip too |
| 10:44 | <krit> | annevk: shape-outside as well |
| 10:45 | <krit> | annevk: which has same-origin restrictions at the moment IIRC |
| 10:45 | <krit> | annevk: http://dev.w3.org/csswg/css-shapes/#shape-outside-property |
| 10:46 | <krit> | annevk: see <image> |
| 10:46 | <krit> | annevk: CORS enabled fetch |
| 10:47 | <annevk> | Fonts have something similar, so I guess CSS is already a bit of a mismatch between things |
| 10:49 | krit | head out for lunch |
| 10:58 | <Ms2ger> | SVG iframe element? Wat? |
| 11:00 | <roc> | yes, I'm not a fan either |
| 11:01 | <Ms2ger> | Do we expect Intent to Implement for preffed-off features? |
| 11:03 | <annevk> | Ms2ger: wrong channel? But I think so |
| 11:03 | <Ms2ger> | I'm pretty sure I haven't seen one for SVG iframes |
| 11:38 | <Ms2ger> | Anyone else having trouble reaching krijn? |
| 11:39 | <annevk> | Ms2ger: he seems to be doing some cycling |
| 11:39 | <Ms2ger> | Carrying his server? |
| 11:56 | <krit> | Ms2ger: roc: Not a fan of it as well. But maybe from a different perspective? I don’t like the duplication of code… tho could be done with <foreignObject …><html><iframe/></html></foreignObject> today. At least in theory. Just Firefox allows iframe as ancestor of <foreignObject>. |
| 11:59 | <roc> | Ms2ger: powercycling perhaps? |
| 11:59 | <roc> | krit: you mean descendant |
| 11:59 | <krit> | roc: right |
| 12:03 | <Ms2ger> | krit, sure, but fixing browser bugs by implementing new features doesn't really work |
| 12:05 | <krit> | Ms2ger: I don’t like having iframe in HTML NS and another one in SVG NS. Even though both use the same code in the background. And I am not saying that it is intend to be a work around for browser bugs. |
| 12:06 | <Ms2ger> | Oh, misread, then |
| 12:08 | <roc> | annevk: oh boy. https://svgwg.org/svg2-draft/embedded.html |
| 12:08 | <roc> | annevk: I did not know about this. |
| 12:08 | <Ms2ger> | SVG 2 Requirement: - Have a video element in SVG namespace with the same characteristics as the HTML 5 video element. |
| 12:08 | <Ms2ger> | - Support 'canvas' element in SVG 2 |
| 12:08 | <Ms2ger> | Nice |
| 12:09 | Ms2ger | volunteers roc to keep an eye on the SVGWG |
| 12:16 | <annevk> | roc: not sure if we should do any of that |
| 12:17 | <roc> | it looks crazy to me |
| 12:17 | <Ms2ger> | Yay, namespaces! |
| 12:18 | <krit> | annevk: well, we should keep image! |
| 12:18 | <krit> | the rest won’t survive the CR period |
| 12:18 | <krit> | (and foreignObject should stay as well… for legacy) |
| 12:19 | <Ms2ger> | Let's kick it out before CR? |
| 12:19 | <roc> | people are trying to implement SVGIframeElement for Gecko |
| 12:19 | <roc> | we need to kick it out now |
| 12:19 | <krit> | roc: they do? |
| 12:19 | <roc> | yep |
| 12:19 | <annevk> | roc: why was there no email to dev.platform? |
| 12:19 | <Ms2ger> | Yes |
| 12:19 | <roc> | not us |
| 12:19 | <krit> | roc: didn’t see an intent to implement |
| 12:19 | <roc> | contributors |
| 12:19 | <Ms2ger> | Nope |
| 12:19 | <roc> | right |
| 12:20 | <Ms2ger> | That's what I was complaining about above |
| 12:20 | <roc> | I actually noticed this a month ago, commented in the bug, and then forgot about it. Oops. |
| 12:20 | <krit> | :) |
| 12:20 | <krit> | Do make it clear: I support having video and canvas within SVG content… just not SVG elements for it |
| 12:21 | <roc> | yeah |
| 12:21 | <annevk> | SVG hasn't even explained their version of the <script> element in detail |
| 12:22 | <annevk> | Is there some way to leave comments on the SVG spec that won't get lost? |
| 12:22 | <roc> | www-svg |
| 12:22 | <Ms2ger> | I don't think so |
| 12:22 | <Ms2ger> | Mailing list comments tend to get lost |
| 12:22 | <Ms2ger> | More so if convenient |
| 12:22 | <roc> | you can always point to them and say "I told you so" |
| 12:22 | <roc> | that's the most important thing for me :-) |
| 12:23 | <Ms2ger> | I'd say getting the spec fixed is more important, as is having a clear list of open issues |
| 12:23 | <roc> | maybe |
| 12:24 | <roc> | in practice it's usually easier for me to send an email to a list than file a bug or use some other issue tracker |
| 12:24 | <roc> | so that's what I do |
| 12:24 | <roc> | if I can |
| 12:24 | <Ms2ger> | I didn't say that was easier :) |
| 12:24 | <Ms2ger> | I said it was less likely to get lost |
| 12:25 | <krit> | roc: oh, annevk can do that |
| 12:26 | <krit> | roc: Ms2ger: also, <script> will be specced in the way it is in HTML |
| 12:26 | <Ms2ger> | I'd have suggested heycam, but I need him for IDL |
| 12:27 | <krit> | roc: Ms2ger: there is just a difference how to reference an external script.. which we try to harmonize as well |
| 12:27 | <krit> | Ms2ger: heycam is *just* the chair of the SVG WG… what can he do :P |
| 12:27 | <annevk> | roc: I'll sort it out |
| 12:28 | <Ms2ger> | Fix IDL bugs full-time for the next 6 months :) |
| 12:28 | <krit> | annevk: well, what is there to sort out if we follow HTML on <style>, <script> and the other elements derived from HTML? |
| 12:28 | <roc> | I'm composing an email to www-svg right now :-) |
| 12:29 | <annevk> | oh ok |
| 12:29 | <krit> | annevk: even synchronous loading… event handling and so on is harmonized with HTML now |
| 12:29 | annevk | is preparing some eggs |
| 12:30 | <annevk> | krit: you can't just say "follow", you actually have to write things out and see if it works |
| 12:30 | <annevk> | krit: e.g. <html:style> does not work if there's no associated browsing context |
| 12:31 | <annevk> | krit: seems like SVG wants something else there |
| 12:31 | <krit> | annevk: you have to write that <script> behaves as HTML <script> and reference HTML <script>… no complex wording needed. That was one of the biggest mistakes of SVG 1.1 that it did that |
| 12:31 | <annevk> | Yeah so that is bullshit |
| 12:31 | <krit> | annevk: no it is not |
| 12:31 | <krit> | annevk: it is bullshit to disrespect everything others do |
| 12:33 | <annevk> | ? |
| 12:33 | <annevk> | I just gave an example of why it doesn't work and then you say it does |
| 12:33 | <Ms2ger> | <annevk> Yeah so that is bullshit |
| 12:35 | <MikeSmith> | sloppy work doesn't deserve respect |
| 12:35 | <MikeSmith> | it merits being called what it is |
| 12:36 | <roc> | people do though |
| 12:36 | <MikeSmith> | sure |
| 12:37 | <MikeSmith> | but it's important for people to not get defensive when others point out sloppiness in their work |
| 12:38 | <MikeSmith> | and it's important for them to also understand why people lose patience with sloppiness |
| 12:38 | <krit> | MikeSmith: defensive by asking for respect in the wording you use? That is called politeness. |
| 12:39 | <MikeSmith> | he was just speaking his mind |
| 12:39 | <MikeSmith> | he didn't write that up as a message to the group or the editors |
| 12:39 | jgraham | is convinced that having an argument will solve everything |
| 12:39 | <krit> | MikeSmith: being impolite nearly always results in defensive and offensive behavior which will never lead to better specws |
| 12:40 | <krit> | jgraham: agree |
| 12:40 | <Ms2ger> | I don't think using "bullshit" was necessary or helpful |
| 12:42 | <krit> | anyway, to get back… We, speaking as a member of the SVG WG, always welcome feedback… www-svg is the right email list for that. The chairs are usually good at tracking the feedback we get and bring it up during calls. |
| 12:45 | <krit> | even better are concrete examples that don’t work and suggestions how to improve the situation. |
| 12:46 | <krit> | annevk: so if you could bring up your issue with the associated browsing context and <style> to the www-svg mailing list, this would be very appreciated |
| 12:48 | <krit> | annevk: as said before… the general theme for SVG2 is to harmonize the spec with HTML as much as possible. Browsers mostly do that today anyway. |
| 12:50 | <krit> | annevk: there are even ideas to let SVG elements inherit from HTMLElement… this is an ambitious task that needs a lot of considerations |
| 12:51 | <darobin> | I have to say that's the kind of bullshit that I would welcome heartily |
| 12:51 | <annevk> | Yes it does, can you sympathise with "bullshit" re "no complex wording needed" above? |
| 12:52 | <annevk> | roc: are you going to give feedback about <iframe> and such or should I? |
| 12:55 | <roc> | I will |
| 12:57 | <Ms2ger> | krit, inherit sounds weird... Right now "implements HTMLElement" === "in the HTML namespace", I'd rather not mess with that invariant |
| 12:58 | <krit> | Ms2ger: yes the namespacing is one of the issues… the biggest one for backwards and forwards compatibility |
| 12:58 | <krit> | Ms2ger: but in the long term.. do we really want to preserve the SVG namespace? |
| 12:59 | <Ms2ger> | I have no love for it |
| 12:59 | <Ms2ger> | But I don't know if that's worth the time to fight with |
| 13:00 | <krit> | Ms2ger: well, we are talking about months of fighting for years or decades of complaining |
| 13:01 | <Ms2ger> | What do you mean by preserving the SVG namespace? |
| 13:01 | <Ms2ger> | There's significant deployed SVG-in-XML that uses i |
| 13:02 | <Ms2ger> | So I suspect browsers won't be able to forget it entirely |
| 13:02 | <krit> | Ms2ger: no, that is indeed a huge part of the discussion |
| 13:03 | <annevk> | You could change the XML parser |
| 13:03 | <Ms2ger> | That's an option, yes |
| 13:03 | <Ms2ger> | Not one I'd take lightly, though |
| 13:04 | <krit> | Ms2ger: there are more issues. One is the <image> element with its different function set than <img> |
| 13:04 | <krit> | Ms2ger: <image> works in most HTML documents today and will create an HTMLImageElement |
| 13:05 | <krit> | Ms2ger: so how to differ between SVG <image> and “HTML” <image> |
| 13:05 | <Ms2ger> | I wish I could forget about that, but I know :/ |
| 13:06 | <krit> | Ms2ger: it goes on with (and we come back to it) <script> and <style> which we are working on harmonizing but certain things are still special for legacy content… like xlink:href on <script> |
| 13:07 | <krit> | Ms2ger: this might require changes to HTML… would HTML be willing to do that? |
| 13:08 | <Ms2ger> | I'm not going to say no without a concrete proposal |
| 13:08 | <Ms2ger> | It seems possible |
| 13:08 | <krit> | Ms2ger: on the other hand… SVG DOM for <style> is mostly useless… it won’t hurt to get rid of it |
| 13:10 | <krit> | Ms2ger: Btw. the Blink team experimented with using the HTML parser even for standalone SVG documents. Missing support for XML entities seemed to be the biggest problem… not a huge problem for newer content though |
| 13:10 | <annevk> | XML entities? |
| 13:10 | <annevk> | People actually declare internal DTDs for SVG? |
| 13:12 | <krit> | annevk: in the past they did |
| 13:20 | <darobin> | I haven't seen that in a while though tbh |
| 13:20 | <darobin> | annevk: a large part of the problem here is that Illustrator would make use of that |
| 13:20 | <darobin> | I think more recent versions don't do that anymore |
| 13:21 | <annevk> | good times |
| 13:26 | <darobin> | annevk: that's possibly the least of the horrors that Illustrators did to SVG :) |
| 13:41 | <annevk> | krit: I updated the algorithm |
| 13:41 | <annevk> | krit: could remove most of it now |
| 14:23 | <zewt> | |
| 14:23 | <zewt> | |
| 14:24 | <zewt> | well okay |
| 15:06 | <JonathanNeal> | What happened to SVG? |
| 15:12 | <TabAtkins> | annevk: I'm convincing blink people that working on "just put SVG in the HTML namespace" is worthwhile. |
| 15:12 | <TabAtkins> | The hoops you have to jump through to get Web components to work with SVG are terrible currently. |
| 15:18 | <darobin> | TabAtkins: that would be awesome |
| 15:20 | <annevk> | TabAtkins: I'm not sure what that means |
| 15:21 | <annevk> | TabAtkins: are you also convincing your employer to employ an editor to work fulltime on fixing SVG? :) |
| 15:28 | <Domenic> | At Lab49 we did a lot of SVG for our banking apps, and it was slow/buggy in Chrome. Might be able to squeeze it into the mobile performance banner. |
| 15:28 | <Ms2ger> | Remove SVG for mobile perf? |
| 15:28 | <Ms2ger> | Be careful what you wish for |
| 15:32 | <jgraham> | If we make SVG the way froward, presto is the rendering engine of the future |
| 15:32 | <jgraham> | *forward |
| 15:54 | <TabAtkins> | annevk: It roughly means what I said: putting svg into the html namespace. |
| 15:54 | <TabAtkins> | Plus the attendant changes to deal with that. |
| 15:55 | <annevk> | TabAtkins: what happens to the SVG namespace? |
| 15:55 | <annevk> | TabAtkins: what classes do they implement? |
| 15:55 | <TabAtkins> | We're working out the details. |
| 15:55 | <annevk> | TabAtkins: in public? |
| 15:55 | <TabAtkins> | It'll be hacky, I'm sure. |
| 15:55 | <TabAtkins> | Once we have an inkling if what might work, yes. |
| 15:56 | <jgraham> | That sounds like "no" |
| 15:57 | <Ms2ger> | I heard "no" too |
| 15:58 | <TabAtkins> | You guys have some strange ears |
| 16:00 | <annevk> | More like strange IRC clients |
| 16:08 | <Ms2ger> | jamesr_, not doing storage mutex stuff by virtue of not doing any storage in Servo |
| 16:08 | <annevk> | Ms2ger: no cookies? |
| 16:08 | <Ms2ger> | None yet |
| 16:25 | <annevk> | darobin: http://discourse.specifiction.org/t/wheres-the-do-not-like-button/341 has been loading for several seconds now |
| 16:25 | <darobin> | annevk: just loaded in a snap from here |
| 16:25 | <annevk> | hmm |
| 16:25 | <darobin> | maybe some temporary hiccup? |
| 16:25 | <annevk> | seems there's occasional hanging |
| 16:25 | <darobin> | I doubled the server's power about a week ago |
| 16:26 | <darobin> | so far the load seems to be okay; but please don't hesitate to tell me again and I might double it again |
| 16:27 | <caitp> | http://jsfiddle.net/d29gj/ who's idea was this? |
| 16:27 | <caitp> | smh .v. |
| 16:30 | <caitp> | does it not, I don't know, make sense to maybe throw a type error or something if a form control's name is a property from lets say, Node or something, to avoid that nonsense? I mean really @_@ |
| 16:31 | <jgraham> | No, the design problem is that name shadows properties at all |
| 16:31 | <caitp> | yes |
| 16:32 | <caitp> | well, that whole scenario is pretty sad =( jeeze |
| 16:33 | <Domenic> | Good ol' @HTML5_Chewbacca managed to get the word out about <picture> landing: https://twitter.com/HTML5_Chewbacca/status/479277675853651968 |
| 16:38 | <caitp> | anyways, was that introduced in html of old, is that one of the more recent failures? I want to know if it's too late to file a bug about that nonsense |
| 16:39 | <jgraham> | Umm, that's actually pretty insulting |
| 16:39 | <jgraham> | :) |
| 16:39 | <caitp> | well it's clearly a failure, the question is if it's too late to fix it or not |
| 16:39 | <jgraham> | I don't think anyone would have introduced that feature in the last 10 years |
| 16:39 | <jgraham> | Far too late |
| 16:40 | <jgraham> | It probably works like that in NS4 or IE5 or something |
| 16:40 | <caitp> | bleh |
| 16:40 | <caitp> | the immobility of this stuff is really disheartening =) |
| 16:44 | <annevk> | mounir: is denying of locking exceptional? https://www.w3.org/Bugs/Public/show_bug.cgi?id=25054#c8 |
| 16:44 | <annevk> | mounir: otherwise you should not reject the promise |
| 16:47 | <annevk> | Domenic: that bit about promises is really unintuitive at the moment |
| 16:47 | <annevk> | Domenic: it makes more sense in the try await catch world, but now... |
| 16:47 | <Domenic> | it seems reasonable, for a method named lockOrientation, that if you can't lock the orientation, it's an exceptional condition |
| 16:48 | <Domenic> | if it were named canLockOrientation(), then getting back "no" would not be exceptional |
| 16:48 | <Domenic> | if it were named "requestToLockOrientation()," then the answer is kind of wishy-washy. |
| 16:49 | <Domenic> | but yes, you should generally assume any time you reject a promise, that is essentially like throwing an exception, especially since people coding with try/catch/await will have exactly that experience. |
| 16:49 | <jgraham> | Yeah, it seems like if it were sync code you might well implement it with an exception |
| 16:54 | <mounir> | annevk: the entire lock flow assume that the lock happened when the promise succeeds |
| 16:56 | <Hixie> | zcorpan: yeah that's not a bad idea |
| 17:06 | <SamB> | so, any reason why it shouldn't *be* an exception? |
| 17:07 | <SamB> | I mean, I see no reason why exceptions can only be transported by throwing |
| 17:41 | <Hixie> | jgraham: you around? i'm getting an assertion trying to use html5lib instead of lxml.html |
| 17:41 | <Hixie> | in your anolis instance |
| 17:42 | <Hixie> | assert isinstance(buffer, bytes) is throwing, in detectEncodingMeta in inputstream.py |
| 18:09 | <gsnedders> | Hixie: anolis should just serialize attributes in alphabetical order |
| 18:09 | <gsnedders> | Hixie: and if that assertion is being hit something is badly wrong :| |
| 18:10 | <Hixie> | i'm apparently using "serializer=alllib" too, i guess i should change that to html5lib |
| 18:10 | <gsnedders> | alllib? what on earth is that |
| 18:10 | <Ms2ger> | ^ |
| 18:10 | Hixie | shrugs |
| 18:10 | gsnedders | blames jgraham |
| 18:10 | <Ms2ger> | I think the alphabetical-serializing merged |
| 18:10 | <Hixie> | merged? |
| 18:11 | <gsnedders> | Ms2ger: given I think jgraham hasn't updated PMS in years… |
| 18:11 | <Ms2ger> | That's the new-fangled term for landing a patch |
| 18:11 | <Ms2ger> | gsnedders, I thought he did at some point |
| 18:12 | <gsnedders> | Ms2ger: idk, I ignore all this PMS-related, um, stress |
| 18:12 | <Ms2ger> | I see what you did there |
| 18:14 | <gsnedders> | Gosh darn it Firefox crashing again |
| 18:51 | <IZh> | IZh: Hi. As I see from the standard the e-mail input field's value must consist of [a-zA-Z0-9-] characters in domain part (after @). But what about international domain names? |
| 18:51 | <IZh> | I mean user@москва.рф |
| 18:52 | <Ms2ger> | Punycode |
| 18:52 | <Ms2ger> | There is no requirement that the user sees ASCII, note |
| 18:53 | <IZh> | Ms2ger: but should a user know it's ugly e-mail version? |
| 18:53 | <Ms2ger> | No, the user could enter the internationalized version |
| 18:54 | <IZh> | And a browser will transparently convert the value? |
| 18:59 | <gsnedders> | IZh: yes |
| 18:59 | <caitp> | I don't think browsers currently do transparently convert the value, I checked that a few weeks ago when it was brought up on angular |
| 18:59 | <caitp> | unless it's locale-dependent or something |
| 19:00 | <gsnedders> | IZh: or at least that is the intention |
| 19:00 | <gsnedders> | IZh: the spec only defines the over-the-wire format and at the JS API; what the browser displays in the UI is tangential |
| 19:06 | <IZh> | I mean, if non-ascii value is not acceptable in JS, then a browser must do the convertion. |
| 19:07 | <IZh> | Or user will enter an international value and it could be considered as invalid by a browser. |
| 19:08 | <gsnedders> | But the user doesn't see the JS API. |
| 19:09 | <gsnedders> | They see whatever widget the browser provides. |
| 19:10 | <gsnedders> | How inputs in the widget map to values exposed at the JS level is up to the browser |
| 19:12 | <IZh> | Yes. But if a user will type user@москва.рф, then will it be considered invalid by browser according to the spec? |
| 19:13 | <gsnedders> | The spec makes no comment on such things. |
| 19:13 | <gsnedders> | The spec makes no requirements on UI. |
| 19:13 | <caitp> | http://jsfiddle.net/UMrw6/ yeah still no punicod-ification, need to polyfill that stuff =( |
| 19:13 | <caitp> | kind of unfortunate |
| 19:13 | <gsnedders> | An extreme example would be exposing input@type="date" (which uses the Georgian calendar at a JS/wire level) as another calendar in the UI, esp. in locales where other calendars are the default |
| 19:15 | <caitp> | gsnedders; the spec actually does comment on that |
| 19:15 | <caitp> | although I guess it's not normative per se, but |
| 19:16 | <gsnedders> | caitp: okay, only my latter statement was true |
| 19:16 | <caitp> | right, that is true |
| 19:16 | <IZh> | Ah... I see. The phrase " The value attribute, if specified and not empty, must have a value that is a single valid e-mail address." is related to only markup's and JS' provided values, and not to a value that is typed by user. |
| 19:17 | <Ms2ger> | Correct |
| 19:18 | <gsnedders> | IZh: The obvious example of this is to look at implementations of input@type="color" |
| 19:18 | <gsnedders> | IZh: Most don't expose the raw value anywhere |
| 19:21 | <IZh> | I see... |
| 20:51 | <Hixie> | gsnedders: even more obvious is type=password |
| 22:06 | <SamB> | hmm, where are the same-origin rules codified these days ... |
| 22:09 | <Hixie> | which ones? |
| 22:09 | <Hixie> | the same-origin policy pervades the entire platform |
| 22:15 | <smaug____> | anyone here familiar with dart2js? |
| 22:16 | <smaug____> | (if the whole thing is still being developed at all) |
| 22:17 | <smaug____> | ah, #dart |
| 22:17 | <SamB> | Hixie: well, I'm wondering about the definition of "same", and the interface for setting the origin to a more accessible value |
| 22:18 | <SamB> | and, like, what do different ports do to things? |
| 22:19 | <SamB> | or, say, http:// vs https:// vs ftp:// ? |
| 22:19 | <Hixie> | the definition of "same" is http://whatwg.org/html#same-origin |
| 22:19 | <Hixie> | not sure what "the interface for setting the origin to a more accessible value" means |
| 22:20 | <Hixie> | nor what you mean by "things" |
| 22:20 | <Hixie> | though i think the definition of "same" might answer that? |
| 22:20 | <SamB> | forget the "and, " before the "like, " there |
| 22:21 | <SamB> | so, yeah |
| 22:23 | <SamB> | Hixie: ah, nice, that's exactly what I was looking for |
| 22:23 | <SamB> | Hixie: anyway, I half expected this section to have been pulled out into its own spec |
| 22:23 | <Hixie> | it might be in the origin RFC as well? |
| 22:23 | <Hixie> | i'm not sure what the state of that is |
| 22:24 | <Hixie> | (i try to keep the number of specs down where possible) |
| 22:24 | <SamB> | meh @ IETF |
| 22:24 | <SamB> | except opus seems pretty cool |
| 22:26 | <SamB> | (even if it is missing the "expected results" half of its test suite ...) |
| 22:26 | <rillian> | SamB: you mean the opus test suite? |
| 22:26 | <SamB> | yeah |
| 22:26 | <rillian> | there's validation code in the RFC |
| 22:27 | <SamB> | hmm |
| 22:27 | <SamB> | maybe they just need a README in that directory on their website or something then |
| 22:27 | <rillian> | I keep meaning to run it through emscripten and make a browser test page with it |
| 22:28 | <SamB> | how does it work? |
| 22:28 | SamB | goes to see if he can understand it ... |
| 22:28 | <rillian> | https://tools.ietf.org/html/rfc6716#section-6.1 |
| 22:29 | <rillian> | the idea with opus_compare is to do a fuzzy-match, so we can declare implementations compliant even if they're not bit-exact |
| 22:29 | <rillian> | giving implementors freedom to optimize the code |
| 22:30 | <SamB> | Hixie: I'm kind of surprised there isn't a "domain name to ASCII" algorithm that converts a whole name to ASCII, putting dots between the components ... |
| 22:30 | <rillian> | there's also a smaller set for testing the .opus file encapsulation implementation. I'll agree with you that side isn't complete. |
| 22:34 | <Hixie> | SamB: http://url.spec.whatwg.org/#concept-domain-to-ascii |
| 22:34 | <Hixie> | oh nevermind |
| 22:35 | <Hixie> | that's still per-label |
| 22:35 | <Hixie> | or no? |
| 22:35 | <Hixie> | http://url.spec.whatwg.org/#concept-domain doesn't make sense to me |
| 22:35 | <Hixie> | what does "the form of a domain" look like? |
| 22:36 | <Hixie> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26138 |
| 22:38 | <SamB> | rillian: I guess I'd basically want to see some files like the ones on http://www.opus-codec.org/examples/ alongside the opus versions, at least |
| 22:39 | <SamB> | though I might have expected FLAC rather than .wav |
| 22:40 | <rillian> | SamB: for human listening tests? |
| 22:40 | <SamB> | rillian: I mean, I understand that implementations aren't required to use any particular output sampling rate |
| 22:43 | <SamB> | but you could downsample, say, 48k sample decodings to whatever output rate you're actually working at and test if the output is plausibly close, yeah? |
| 22:43 | <SamB> | or, worst case, do it by ear, yes |
| 22:44 | <rillian> | SamB: that's what opus_compare tries to do |
| 22:44 | <rillian> | part of the problem is that there are both fixed and floating point implementations |
| 22:44 | <rillian> | so you can exactly verify the entropy coder output, but not the audio output |
| 22:45 | <rillian> | how would you test 'plausibly close'? |
| 22:46 | <SamB> | well, I'd *probably* start by transforming to the frequency domain |
| 22:47 | <rillian> | https://git.xiph.org/?p=opus.git;a=blob;f=src/opus_compare.c |
| 22:47 | <SamB> | or possibly by buying a DSP book, or at least another signal processing book since someone lost the one I had for school ... |
| 22:49 | <SamB> | hmm, I suck at googling and chatting at the same time ;-) |
| 22:51 | <rillian> | it looks like it splits the audio into overlapped blocks, does a rough transform, and applies some psychoacoustic stuff |
| 22:51 | <SamB> | anyway, I guess http://people.xiph.org/~greg/opus_testvectors/ is the one I was confused by |
| 22:51 | <SamB> | and I was thinking for decode testing; encoder testing is obviously MUCH more involved |
| 22:51 | <rillian> | yeah, that could use a readme |
| 22:55 | <SamB> | Hixie: I really miss the days when I could use the single-page spec; too bad I have no real idea what changed that makes that so unpleasant now ... |
| 22:55 | <Hixie> | what browser? |
| 22:56 | <SamB> | well, ISTR it used to work okay in Chrome, but no more. Not sure if it was something on your end or Chrome's end, even ... |
| 22:56 | <Hixie> | chrome sucking on the html spec these days is https://code.google.com/p/chromium/issues/detail?id=376847 |
| 22:56 | <SamB> | I mean, *something* started demanding more RAM, but I'm not sure what ... |
| 22:57 | <SamB> | not sure if it worked okay in Firefox or not |
| 22:57 | <Hixie> | firefox is fine once it's loaded |
| 22:57 | <Hixie> | but loading the spec in firefox is painful |
| 22:57 | <Hixie> | not sure if they have a bug on that |
| 22:57 | <SamB> | how much memory does it use once it's loaded? |
| 22:57 | <Hixie> | in which? |
| 22:58 | <SamB> | firefox |
| 22:59 | <Hixie> | about half a gig |
| 22:59 | <Hixie> | (including the browser) |
| 22:59 | <Hixie> | chrome uses a little over a quarter of a gig (not including the browser) |
| 22:59 | <Hixie> | memory isn't the issue though |
| 23:01 | <SamB> | it is *an* issue for me |
| 23:02 | <Hixie> | buy more ram |
| 23:02 | <Hixie> | :-) |
| 23:04 | <SamB> | yeah, iirc the SMBIOS data on this thing claims I can triple my RAM by doubling the size of the existing modules and installing a third, but I'm not positive the third slot actually exists |
| 23:04 | <Hixie> | heh |
| 23:05 | <Hixie> | how much ram do you have? |
| 23:05 | <SamB> | 1 gig :-( |
| 23:05 | <Hixie> | 1 gig! |
| 23:06 | <Hixie> | what is this, 1997? :-P |
| 23:06 | <Hixie> | ok filed https://bugzilla.mozilla.org/show_bug.cgi?id=1027382 on firefox hanging while loading the html spec |
| 23:07 | <SamB> | dude, the computer we got in, like, 1996 or 1997 came with 16 megs and my dad had to upgrade it to 32 megs |
| 23:07 | <zewt> | Hixie: fwiw, I think refusing to adjust the spec when it's doing uncommon things (an unusually large page doing unusual things with CSS) to try to force browsers to do optimizations that they don't have time to do is unreasonable and harmful |
| 23:08 | <SamB> | zewt: he's doing that? |
| 23:08 | <SamB> | I mean, on purpose? |
| 23:08 | <Hixie> | zewt: it's not that unusual, and firefox handles it perfectly. Plus, until recently the situation was reversed (the CSS did something that hurt Firefox, but not Chrome, because Chrome cheated), so it's about time the tables were turned. |
| 23:08 | <zewt> | that's what my takeaway was from https://code.google.com/p/chromium/issues/detail?id=376847#c26 |
| 23:10 | <zewt> | i'm sure there are tons of cases where either browser is faster than the other; I think the HTML spec is the wrong place to wage these battles (all it means is today, I'm much less likely to load the spec to answer a question than I was a couple months ago) |
| 23:11 | <Hixie> | it's not like this is on purpose |
| 23:11 | <Hixie> | i just wrote CSS that should work, and it did work |
| 23:11 | <Hixie> | except in chrome |
| 23:11 | <zewt> | making the spec convenient to access is far more important than trying to coerce a browser into making some whack-a-mole CSS optimization |
| 23:11 | <smaug____> | Hixie: fixing that responsiveness issue in FF needs multiprocess setup. That way UI wouldn't be blocked, only the child process. Similar to Chrome, where scrolling or resizing while loading html spec isn't working too well. |
| 23:11 | <Hixie> | smaug____: yeah, that was my guess too |
| 23:12 | <smaug____> | (fortunately e10s project is doing quite well) |
| 23:12 | <smaug____> | I do profile html spec loading occasionally |
| 23:12 | <SamB> | zewt: I don't think it counts as what you said unless he's insisting on sticking with his original approach in the face of a reasonable alternative |
| 23:13 | <Hixie> | SamB: i haven't looked into what an alternative would look like |
| 23:13 | <Hixie> | SamB: but i'm sure it'd be possible to find one |
| 23:13 | <SamB> | so, um, is there some way to let firefox take a breather during the loading process |
| 23:13 | <zewt> | someone recommended something on the ticket, iirc |
| 23:14 | <smaug____> | SamB: it is mostly layout stuff... need to improve interruptible layout |
| 23:14 | <roc> | In Firefox nightlies you can actually open the HTML5 spec in a separate process tab, so problem solved if you remember to do that :-) |
| 23:14 | <SamB> | Hixie: also, it sounds kind of unreasonable to expect a transition that impacts every element to be too quick |
| 23:14 | <SamB> | smaug____: ah |
| 23:14 | <Hixie> | SamB: it's blazing fast in firefox |
| 23:15 | <Hixie> | SamB: not even a slight hickup |
| 23:15 | <Hixie> | SamB: buttery smooth 60fps goodness |
| 23:15 | <SamB> | Hixie: huh, what properties ... |
| 23:15 | SamB | goes to check |
| 23:15 | <smaug____> | SamB: chrome is equally bad too with resizing the window for example |
| 23:15 | <Hixie> | roc: how do i do that? |
| 23:15 | <Hixie> | roc: i mean, i only have this one page open... |
| 23:16 | <Hixie> | roc: but as soon as i try to open the spec, it messes up command-tabbing around the OS and so on, because it doesn't respond any more |
| 23:16 | <SamB> | Hixie: presumably it has the client area in the other process but the chrome still in the main process |
| 23:16 | <SamB> | oh, it screws with the OS? |
| 23:16 | <zewt> | reasonable to expect it or not, having the spec be fast and convenient for everyone is so much more important than any style changes (the spec was perfectly fine before, IMO) |
| 23:17 | <smaug____> | in the menu FF has open New e10s Window |
| 23:17 | <smaug____> | one may need to do Customize first, I think |
| 23:17 | <Hixie> | roc: yeah, i just created a new e10s window and while the page is loading, if i command-tab to another app, the window stays up |
| 23:17 | <zewt> | "e10s"? is that supposed to be meaningful? heh |
| 23:17 | <Hixie> | roc: and if i click on another app then command-tab back to firefox, the window doesn't show |
| 23:17 | <Hixie> | zewt: internal codename |
| 23:17 | <zewt> | heh okay |
| 23:17 | <SamB> | anyway, *my* problems probably started >1y ago ... |
| 23:18 | <Hixie> | zewt: the spec wasn't fine before, we got lots of complaints about the look. but yeah, it's sad that it's slow in chrome, i just don't like working around what are just bugs. |
| 23:18 | <Hixie> | zewt: and since i never worked around firefox bugs, it seems bad that i work around chrome bugs |
| 23:19 | <SamB> | Hixie: what firefox bugs did you decide not to work around, and why? |
| 23:19 | <Hixie> | some similar performance issue with selectors |
| 23:19 | <Hixie> | and for the same reason |
| 23:19 | <SamB> | "because it was just bugs", not "because the workaround was fugly"? |
| 23:20 | <Hixie> | right |
| 23:20 | <Hixie> | bugs should be fixed :-) |
| 23:20 | <Hixie> | not worked around |
| 23:20 | <SamB> | well, yeah, I guess your hands are tied then |
| 23:20 | <Hixie> | i'll probably end up working around this one eventually if they don't fix it, because it is somewhat more eggregious |
| 23:21 | <SamB> | however, you're perfectly at liberty to work around my lack of RAM, since that's not actually a bug in some vendor's code ;-P |
| 23:21 | <Hixie> | (and zewt is right) |
| 23:21 | <Hixie> | (that the spec being readable is more important) |
| 23:21 | <Hixie> | SamB: that's what the multipage spec is for |
| 23:21 | <SamB> | though I don't expect you to find your own workaround |
| 23:21 | <SamB> | yeah, that does help |
| 23:22 | <SamB> | but still, I miss the nifty crossref thing working document-wide, and Ctrl+F ... |
| 23:24 | <SamB> | Hixie: what is "additional data"? |
| 23:24 | <Hixie> | for origins? |
| 23:24 | <SamB> | yeah |
| 23:24 | <Hixie> | e.g. certification signature or whatever |
| 23:24 | <Hixie> | certificate |
| 23:24 | <Hixie> | probably nothing, in practice |
| 23:28 | <SamB> | hmm, needs more hyperlinks |