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] 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] SVG cloning elements from HTML5
On Tue, 24 Jun 2014, Robert O'Callahan wrote: !DOCTYPE HTML svg span id=s/span div id=i/div the elements s and i are put in the HTML namespace already. As siblings of the svg element, though, not descendants. This was required to get some level of compatibility with deployed content while still allowing svg in HTML. There was content out there that, for reasons that defeat me, had svg start tags (but not end tags). If we had not introduced this limited trap door out of the foreign lands (it's a hard-coded list of tag names that bail out in this way), it would have caused the pages to be blank from the svg start tag to the end. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 9:11 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 24 Jun 2014, Robert O'Callahan wrote: !DOCTYPE HTML svg span id=s/span div id=i/div the elements s and i are put in the HTML namespace already. As siblings of the svg element, though, not descendants. This was required to get some level of compatibility with deployed content while still allowing svg in HTML. There was content out there that, for reasons that defeat me, had svg start tags (but not end tags). If we had not introduced this limited trap door out of the foreign lands (it's a hard-coded list of tag names that bail out in this way), it would have caused the pages to be blank from the svg start tag to the end. That's assuming that HTML content doesn't render in SVG (or that the html tagnames are parsed as unknown SVG elements). Under the proposals for defining an SVG layout model that integrates properly with the other CSS layout models, the content would be displayed. (The current proposal would place all the direct HTML children of SVG elements on top of each other, similar to abspos, but grandchildren would render normally, in a CSS layout model.) ~TJ
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 6:35 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: (The current proposal would place all the direct HTML children of SVG elements on top of each other, similar to abspos, but grandchildren would render normally, in a CSS layout model.) Isn't content outside of svg clipped though? -- http://annevankesteren.nl/
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 9:44 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jun 26, 2014 at 6:35 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: (The current proposal would place all the direct HTML children of SVG elements on top of each other, similar to abspos, but grandchildren would render normally, in a CSS layout model.) Isn't content outside of svg clipped though? Ugh, yeah, svg is overflow:hidden by default. How many of these crazy sites were there? I'd hate to flounder on such an important change due to just a handful of idiotically-authored sites. Better integration of HTML and SVG (and blocking any further element copying beyond the four existing elements) is really important. ~TJ
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 6:48 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: How many of these crazy sites were there? I'd hate to flounder on such an important change due to just a handful of idiotically-authored sites. Better integration of HTML and SVG (and blocking any further element copying beyond the four existing elements) is really important. I remember Ian showing a couple. Instrumenting Blink or Gecko probably gives you a better idea of such sites today. We could also consider making it opt-in somehow, svg html, but that's somewhat ugly if it's only about different parsing behavior. -- http://annevankesteren.nl/
Re: [whatwg] SVG cloning elements from HTML5
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
Re: [whatwg] SVG cloning elements from HTML5
[plain-text email, please. HTML emails rarely survive plain-text-ification unscathed.] On Mon, Jun 23, 2014 at 11:35 PM, Gavin Kistner phr...@me.com wrote: On 24 Jun 2014, at 05:25, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Allowing html directly in svg is definitely the right answer. Parsing shouldn't be too hard, and defining the layout model would be pretty trivial. For layout, we could do this: 1) When an HTML element is a child of an SVG element, perform CSS layout of the HTML element treating the nearest SVG viewport as the containing block. Its user-space width and height become the width and height of the containing block in CSS pixels. 2) Treat such HTML elements as position:relative. We should also support position:absolute. Given that this can then be changed, what happens for position:static? Ignored? Just flow within the school container? I agree that position:relative is a desirable default in this case, but if position:static can be supported then I (lightly) argue that a special case to change the default value inside SVG is a bad idea. It's more code, and less expected for end users. Okay, changing my mind a little bit. Giving more thought here, I think we should: 1. Define that the SVG layout model is a thing. svg elements trigger it automatically, probably via display-inside: svg !important; in the UA stylesheet. (This allows display: whatever; on svg elements to still work correctly, as it would only be able to change display-outside.) 2. Other SVG elements propagate the SVG layout model. This is maybe via a display-outside:svg rule on svg|*:not(svg). We can tweak what approach we use here. 3. Everything in the SVG layout model is positioned relative to the root of an SVG layout model, using x and y properties. 4. That's it. Normal HTML elements use display:inline or display:block or whatever, so they dont' propagate the model; they position themselves via x/y, but their children lay out normally. You can then use 'position' as usual if you want to abspos or whatever, but given the standard position:static, x/y is where it's at. ~TJ
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Yes, increasing the set of name-alikes between html and svg is absolutely not something we'll support. (I've unfortunately been out of the loop with the svgwg for a while, or else I would have prevented this from showing up in the first place.) Allowing html directly in svg is definitely the right answer. Parsing shouldn't be too hard, and defining the layout model would be pretty trivial. I think we should actually figure this out. I'm not an expert on the HTML parser, but it seems to me there's already some support for what we need. E.g. given !DOCTYPE HTML svg span id=s/span div id=i/div the elements s and i are put in the HTML namespace already. For layout, we could do this: 1) When an HTML element is a child of an SVG element, perform CSS layout of the HTML element treating the nearest SVG viewport as the containing block. Its user-space width and height become the width and height of the containing block in CSS pixels. 2) Treat such HTML elements as position:relative. 3) Add x and y attributes to HTMLElement and have them map to left and top CSS properties. (There's a crazy legacy compat issue for HTMLImageElement.x/y but we can hack around that.) 4) Add a transform attribute to HTMLElement and have it map to the transform CSS property. #3 and #4 are optional, there are pros and cons to having them. Using the nearest SVG viewport in #1 is because other SVG container elements don't have a defined size (and we can't use getBBox because that depends on the layout of the children). 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 Jun 24, 2014, at 5:25 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Yes, increasing the set of name-alikes between html and svg is absolutely not something we'll support. (I've unfortunately been out of the loop with the svgwg for a while, or else I would have prevented this from showing up in the first place.) Allowing html directly in svg is definitely the right answer. Parsing shouldn't be too hard, and defining the layout model would be pretty trivial. I think we should actually figure this out. I'm not an expert on the HTML parser, but it seems to me there's already some support for what we need. E.g. given !DOCTYPE HTML svg span id=s/span div id=i/div the elements s and i are put in the HTML namespace already. For layout, we could do this: 1) When an HTML element is a child of an SVG element, perform CSS layout of the HTML element treating the nearest SVG viewport as the containing block. Its user-space width and height become the width and height of the containing block in CSS pixels. 2) Treat such HTML elements as position:relative. 3) Add x and y attributes to HTMLElement and have them map to left and top CSS properties. (There's a crazy legacy compat issue for HTMLImageElement.x/y but we can hack around that.) We will have the x, y properties. No need to map to left and right. 4) Add a transform attribute to HTMLElement and have it map to the transform CSS property. In this case we should think about making transform a presentation attribute in general for HTML and SVG. #3 and #4 are optional, there are pros and cons to having them. Using the nearest SVG viewport in #1 is because other SVG container elements don't have a defined size (and we can't use getBBox because that depends on the layout of the children). Greetings, Dirk
Re: [whatwg] SVG cloning elements from HTML5
On Mon, Jun 23, 2014 at 9:35 PM, Dirk Schulze dschu...@adobe.com wrote: On Jun 24, 2014, at 5:25 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Yes, increasing the set of name-alikes between html and svg is absolutely not something we'll support. (I've unfortunately been out of the loop with the svgwg for a while, or else I would have prevented this from showing up in the first place.) Allowing html directly in svg is definitely the right answer. Parsing shouldn't be too hard, and defining the layout model would be pretty trivial. I think we should actually figure this out. I'm not an expert on the HTML parser, but it seems to me there's already some support for what we need. E.g. given !DOCTYPE HTML svg span id=s/span div id=i/div the elements s and i are put in the HTML namespace already. For layout, we could do this: 1) When an HTML element is a child of an SVG element, perform CSS layout of the HTML element treating the nearest SVG viewport as the containing block. Its user-space width and height become the width and height of the containing block in CSS pixels. 2) Treat such HTML elements as position:relative. 3) Add x and y attributes to HTMLElement and have them map to left and top CSS properties. (There's a crazy legacy compat issue for HTMLImageElement.x/y but we can hack around that.) We will have the x, y properties. No need to map to left and right. Yeah, this is part of the general SVG/CSS convergence effort, already approved and under way. 4) Add a transform attribute to HTMLElement and have it map to the transform CSS property. In this case we should think about making transform a presentation attribute in general for HTML and SVG. That's effectively what it would do, yes. #3 and #4 are optional, there are pros and cons to having them. Using the nearest SVG viewport in #1 is because other SVG container elements don't have a defined size (and we can't use getBBox because that depends on the layout of the children). Yes, using the nearest svg was my plan as well. ~TJ
Re: [whatwg] SVG cloning elements from HTML5
On 6/18/14, 8:59 AM, Robert O'Callahan wrote: For example, SVGIframeElement as specced has two width attributes. Which actually means the IDL will fail to be parsed with a conforming Web IDL parser. SVGIframeElement implements HTMLIFrameElement creates a multiple inheritance situation that I don't think any engine would really want to implement, even if it made sense, which I don't think it does. For what it's worth, all that line means is copy all the methods/properties from HTMLIframeElement.prototype and its ancestors to SVGIframeElement.prototype. No multiple inheritance involved per se. Of course in this case both HTMLIframeElement and SVGIframeElement ultimately inherit from Element and Node, but as WebIDL is currently written I believe all that implements statement will do is also copy all the Node and Element stuff onto SVGIframeElement.prototype. This will, of course, greatly confuse authors who try to hook things on Element.prototype and discover it works for every element except SVGIframeElement... In any case, whether the implementations of those methods/properties make sense after the copying is done depends on exactly how they're written. I strongly doubt the HTMLIframeElement ones are all written in a generic enough way, so this would definitely need coordination with the HTML editor. Fully agreed on the rest of your mail about this not being the way to go, if that wasn't clear. ;) And I strongly recommend running any draft IDL through an actual conforming IDL parser and not publishing any drafts with invalid IDL. -Boris
Re: [whatwg] SVG cloning elements from HTML5
On Jun 18, 2014 6:00 AM, Robert O'Callahan rob...@ocallahan.org wrote: I just discovered https://svgwg.org/svg2-draft/embedded.html This looks very problematic. It ties SVG and HTML5 together in uncomfortable ways. For example, SVGIframeElement as specced has two width attributes. It's unclear how to keep this making sense as SVG and HTML5 evolve, e.g. as new attributes get added to HTML5 elements. It will be easy to change HTML5 in ways that break this SVG spec (and possibly vice versa). SVGIframeElement implements HTMLIFrameElement creates a multiple inheritance situation that I don't think any engine would really want to implement, even if it made sense, which I don't think it does. I'm pretty sure no-one who actually works on HTML5 has approved of this. Yes, it's only in a draft, but people are already taking that as a cue to start implementing. I think we need to take a step back from this, figure out what the goals are and then work together on solving them the right way. It seems to me that if we possibly can, we should solve this by reusing the actual HTML elements so much less spec synchronization is needed. We probably should find a way to support actual HTML elements as direct children of SVG elements with no intervening foreignObject. We should make sure the parser can handle that too, at least for a whitelisted set of elements. Yes, increasing the set of name-alikes between html and svg is absolutely not something we'll support. (I've unfortunately been out of the loop with the svgwg for a while, or else I would have prevented this from showing up in the first place.) Allowing html directly in svg is definitely the right answer. Parsing shouldn't be too hard, and defining the layout model would be pretty trivial. ~TJ
