Re: [whatwg] SVG cloning elements from HTML5
On 26/06/2014 19:06, Tab Atkins Jr. wrote: On Thu, Jun 26, 2014 at 10:40 AM, Chris Lilley ch...@w3.org wrote: Better integration of HTML and SVG (and blocking any further element copying beyond the four existing elements) is really important. Much more important than maintaining rendering of someone's tried this and it didn't do anything but I never took the tags out because they were harmless test page from years ago. Well, I remember one in particular was the page of some soccer club, and definitely not a test page. That said, I'm comfortable with breaking a small number of sites for this change. ~TJ If the parser is changing here could we also change it so that HTML elements don't auto close math for which there was also only ever fragile justification. It would make far more sense if the html elements that currently close math just acted as if they were wrapped in mtext (and so rendered normally, within the math) mathmfracmn1/mnpa/p/mfrac mathmfracmn1/mnmtextpa/p/mtext/mfrac David
Re: [whatwg] High-density canvases
On Thu, Jun 26, 2014 at 6:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Jun 27, 2014 at 2:00 AM, Justin Novosad ju...@google.com wrote: Hadn't thought of that. object-fit seems smells dangerous. I think we may need to define explicit behaviors for renderedPixelWidth/Height for the different object fit modes. I don't think so. Given renderedPixelWidth/Height returns the size of the content box, and the element's CSS width and height are not 'auto', then renderedPixelWidth/Height are not affected by object-fit or the intrinsic size, so there is no feedback loop. I agree there is no feedback loop in the browser, but the event listener may create one. See below. For example, with 'object-fit: contains', will the renderedPixelWidth/Height be computed in a way to fill the element's content area, or will it preserve the aspect ratio of the original intrinsic size? The former. I agree that makes most sense, but because the canvas width and height are integers, there will be some numerical instability and the aspect ratio may drift over time as the canvas gets resized multiple times in succession. This is because the intrinsic size used to compute the the new renderedPixelWidth/Height is presumably the renderedPixelWidth/Height from the previous resize iteration and so-on. Also, with object fit triggering a renderedsizechange event, the event listener will presumably change the intrinsic size of the canvas, which will invalidate style (because the object-fit computation depends on the intrinsic size), and that causes a style invalidation feedback loop. We don't implement object-fit in Gecko yet, but when we do the change to the intrinsic size will trigger a relayout that will end up not change anything so there is no feedback loop. Whether or not there is a feedback loop is not entirely up to the browser. It depends what the event listener does. Control flow: 1) CSS size of the canvas is modified 2) layout - renderedPixelWidth/Height are recomputed based on the new content box dimensions 3) if renderedPixelWidth/Height are unchanged jump to step 7 4) renderedsizechange event is fired 5) renderedsizechange event handler changes the canvas's intrinsic size. 6) if the canvas's intrinsic size changed and the element uses object-fit, then jump to step 2. (feedback loop) 7) Paint page content For this not to loop indefinitely depends on the event listener having stable behavior. If the listener just sets the canvas size to renderedPixelWidth/Height, I am pretty sure this will always be fine (two pass layout). But in the case where the event listener does something like this, it may take several more layout iterations for things to stabilize, or it may oscillate indefinitely. Example of a problematic renderedsizechange event listener: canvas.width = Math.floor(canvas.renderedPixelWidth * myPixelScale); canvas.height = Math.floor(canvas.renderedPixelHeight * myPixelScale); This behavior seems sound at first glance, but because that arithmetic may induce a change to the intrinsic aspect ratio due to rounding, step 3) may not jump out of the loop during the second iteration, thus allowing the feedback loop to keep spinning. -Justin Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] SVG cloning elements from HTML5
On 27/06/2014 19:01, Tab Atkins Jr. wrote: On Fri, Jun 27, 2014 at 2:16 AM, David Carlisle dav...@nag.co.uk wrote: If the parser is changing here could we also change it so that HTML elements don't auto close math for which there was also only ever fragile justification. Yes, no reason to exclude math here. It should be consistent. It would make far more sense if the html elements that currently close math just acted as if they were wrapped in mtext (and so rendered normally, within the math) mathmfracmn1/mnpa/p/mfrac mathmfracmn1/mnmtextpa/p/mtext/mfrac Or, slightly better, also define a math layout mode, which currently only math elements can activate via hidden, unseeable magic (currently). Then define how other layout modes act when inserted into the math layout model, like we're doing with the svg layout model. ~TJ Speaking for myself here (but I wouldn't expect the Math WG to disagree) we'd be happy to work on whatever is needed here to make html/math/svg a coherent document format (that hopefully you might even implement:-) with as far as possible historic differences because of the different origins of the languages blurred to current users. Who do you mean by we in the above (css wg, svg wg, whatwg here) not that it matters really but if I need to go and ask the Math WG to coordinate with someone I want to be able to say who that is:-) David
Re: [whatwg] SVG cloning elements from HTML5
On Fri, Jun 27, 2014 at 2:11 PM, David Carlisle dav...@nag.co.uk wrote: Who do you mean by we in the above (css wg, svg wg, whatwg here) not that it matters really but if I need to go and ask the Math WG to coordinate with someone I want to be able to say who that is:-) Me, mostly, but CSSWG if you need a WG. ~TJ
Re: [whatwg] High-density canvases
On Sat, Jun 28, 2014 at 3:41 AM, Justin Novosad ju...@google.com wrote: Example of a problematic renderedsizechange event listener: canvas.width = Math.floor(canvas.renderedPixelWidth * myPixelScale); canvas.height = Math.floor(canvas.renderedPixelHeight * myPixelScale); I don't know why anyone would actually want to do this. This behavior seems sound at first glance, but because that arithmetic may induce a change to the intrinsic aspect ratio due to rounding, step 3) may not jump out of the loop during the second iteration, thus allowing the feedback loop to keep spinning. What are the specified values of CSS 'width' and 'height' on the canvas in your example? Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
