Re: [whatwg] questions on URL spec based on reviewing galimatias test results
On 10/29/14 4:47 AM, Anne van Kesteren wrote: On Wed, Oct 29, 2014 at 12:12 PM, Sam Ruby wrote: 1) Is the following expected to produce a parse error: http://intertwingly.net/projects/pegurl/urltest-results/4b60e32190 ? My reading of https://url.spec.whatwg.org/#relative-path-state is that step 3.1 indicates a parse error even though later step 1.5.1 replaces the non URL code point with a colon. My proposed reference implementation does not indicate a parse error with these inputs, but I could easily add it. Given the legacy aspect, probably should be an error. Fixed: https://github.com/rubys/url/commit/6789a5307ebd0e4aa05161c93038f2fc50011955 But it turns out that addressing that question opens up another question. In my implementation that fix caused a (recoverable) parse error to be produced for another test case: http://intertwingly.net/projects/pegurl/urltest-results/d674c14cbe I'll note that galimatias doesn't produce a parse error in this case (and, in fact, the state machine specified by the current URL Standard goes down a completely different path for this case). The question is: should this be a parse error? - Sam Ruby
[whatwg] allow in body + DOM position as a rendering hint
(based on discussion at the webperf group meeting at TPAC... hopefully I captured the discussion correctly. If not, please jump in!) HTML5 spec: "If the rel attribute is used, the element is restricted to the head element." [1] Above language is too restrictive, allowing link element to be present in the body (as many sites already do, and all browsers support), would enable useful performance optimizations for stylesheets in particular - e.g. IE treats stylesheets in as render blocking and will hold page rendering until they are downloaded and executed, however a within body is treated as render blocking for DOM-content before its declaration (although, this behavior is only triggered as an error condition based on some additional timeouts). Above IE behavior enables faster first-paint for "above the content" and is already in use by some developers - i.e. sites are *forcing* the IE error condition to deliver faster paints. /* critical css */ ... ... In above example content may be painted by the browser before other.css is downloaded and processed. Effectively, the position of the element in the document acts as a hint to the UA that it may (not must) paint the DOM-content before it without blocking on it. To be clear, this proposal does *not* change any existing semantics of CSS. Once processed, other.css *may* impact rendering of the content above it (it's applied against global context), which may cause reflows, etc. However, a well implemented site can avoid unnecessary reflows+paints by splitting relevant styles in a way that minimizes interaction between various sections. Baidu team has prototyped something similar via their "First Screen Paint In Advance" proposal [2] and saw significant improvement in rendering times on mobile devices. tl;dr: proposal is... 1) allow link tags in the body 2) add a note to implementors: consider treating link tags in body as a hint to the UA that what is above the link tag (in DOM order) should not be blocked on painting Above behavior is already deployed in the wild (both on sites and implemented in some browsers), and helps deliver faster first paints, as evidenced by Baidu and IE experience. Based on discussion at the TPAC meeting, there was interest from IE, Chrome, and Safari (we didn't have anyone from Mozilla to comment) in exploring this further... However, that would require some spec updates on HTML front. Thoughts? [1] http://www.w3.org/TR/html5/document-metadata.html#the-link-element [2] http://www.w3.org/Submission/first-screen-paint/
Re: [whatwg] New feature: better integration with browser find interface
On Thu, Oct 30, 2014 at 9:15 AM, Peter Kasting wrote: > If browsers had to retry open "find"s every time the page content changed, > then leaving one's find bar open could have very large negative performance > effects, even if the browser focused only on the modified pieces of the > page. Is there an implementation idea I'm missing for how browsers could > fix this "bug" in a performant way? Otherwise I can't see us doing what it > seems like you want. > It seems possible to me: 1) You can do it lazily, during idle time (though some apps don't have any) 2) You can do it incrementally 3) You can start with the visible part of the page Having said that, it would be complex enough I don't know if it would ever be worth implementing. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Re: [whatwg] New feature: better integration with browser find interface
On Tue, Oct 28, 2014 at 10:59 AM, Ian Hickson wrote: > > - telling UA that it should retry the search because content has been > > changed/rendered/modified > > > > The last is important because for web application which dynamically > > render the content, after search has already find matches on the page, > > if content is changed, browsers do not retry the search. This is the > > most evident with browsers which allow "highlight all" feature, like > > Google Chrome. > > This is just a bug in the browsers. If browsers had to retry open "find"s every time the page content changed, then leaving one's find bar open could have very large negative performance effects, even if the browser focused only on the modified pieces of the page. Is there an implementation idea I'm missing for how browsers could fix this "bug" in a performant way? Otherwise I can't see us doing what it seems like you want. PK
Re: [whatwg] questions on URL spec based on reviewing galimatias test results
On Wed, Oct 29, 2014 at 1:26 PM, Sam Ruby wrote: > Here is another example (though it contains multiple parse errors): > > http://intertwingly.net/projects/pegurl/urltest-results/f3382f1412 > > The error being reported is that the host contains consecutive dot > characters (i.e., the 'label' between these characters is empty). Yeah, that is a clearly an error. Only the last label can be empty. I suspect that part would fail somewhere in the IDNA code. The %3g bit will fail too because % is not allowed. -- https://annevankesteren.nl/
Re: [whatwg] questions on URL spec based on reviewing galimatias test results
On 10/29/14 4:47 AM, Anne van Kesteren wrote: On Wed, Oct 29, 2014 at 12:12 PM, Sam Ruby wrote: 2) Is the following expected to product a parse error: http://intertwingly.net/projects/pegurl/urltest-results/bc6ea8bdf8 ? What is the DNS violation supposed to mean? I would expect this to change if we decide to parse any numeric host name into IPv4. Then it would certainly be an error. Here is another example (though it contains multiple parse errors): http://intertwingly.net/projects/pegurl/urltest-results/f3382f1412 The error being reported is that the host contains consecutive dot characters (i.e., the 'label' between these characters is empty). - Sam Ruby
Re: [whatwg] questions on URL spec based on reviewing galimatias test results
On Wed, Oct 29, 2014 at 12:12 PM, Sam Ruby wrote: > 1) Is the following expected to produce a parse error: > > http://intertwingly.net/projects/pegurl/urltest-results/4b60e32190 ? > > My reading of https://url.spec.whatwg.org/#relative-path-state is that step > 3.1 indicates a parse error even though later step 1.5.1 replaces the non > URL code point with a colon. > > My proposed reference implementation does not indicate a parse error with > these inputs, but I could easily add it. Given the legacy aspect, probably should be an error. > 2) Is the following expected to product a parse error: > > http://intertwingly.net/projects/pegurl/urltest-results/bc6ea8bdf8 ? What is the DNS violation supposed to mean? I would expect this to change if we decide to parse any numeric host name into IPv4. Then it would certainly be an error. > And the following only defines fatal errors (e.g. step 5); > https://url.spec.whatwg.org/#concept-host-parser > > My proposed reference implementation does indicate a parse error with these > inputs, but this could easily be removed. Fatal errors are just worse parse errors. The difference is that a fatal error can be observed through an API. -- https://annevankesteren.nl/
[whatwg] questions on URL spec based on reviewing galimatias test results
1) Is the following expected to produce a parse error: http://intertwingly.net/projects/pegurl/urltest-results/4b60e32190 ? My reading of https://url.spec.whatwg.org/#relative-path-state is that step 3.1 indicates a parse error even though later step 1.5.1 replaces the non URL code point with a colon. My proposed reference implementation does not indicate a parse error with these inputs, but I could easily add it. 2) Is the following expected to product a parse error: http://intertwingly.net/projects/pegurl/urltest-results/bc6ea8bdf8 ? I ask this because the error isn't defined here: https://url.spec.whatwg.org/#host-state And the following only defines fatal errors (e.g. step 5); https://url.spec.whatwg.org/#concept-host-parser My proposed reference implementation does indicate a parse error with these inputs, but this could easily be removed. - Sam Ruby
