Re: [whatwg] SVG cloning elements from HTML5
On Fri, Jun 27, 2014 at 2:11 PM, David Carlisle 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 27/06/2014 19:01, Tab Atkins Jr. wrote: On Fri, Jun 27, 2014 at 2:16 AM, David Carlisle 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) 1a 1a 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:16 AM, David Carlisle 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) > > 1a > > 1a 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
Re: [whatwg] SVG cloning elements from HTML5
On Thu, 26 Jun 2014 18:48:38 +0200, Tab Atkins Jr. wrote: On Thu, Jun 26, 2014 at 9:44 AM, Anne van Kesteren wrote: On Thu, Jun 26, 2014 at 6:35 PM, Tab Atkins Jr. 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 clipped though? Ugh, yeah, is overflow:hidden by default. True, and changing that would likely break some svg content. It would be interesting to investigate if it's possible to change so that inline defaults to 'overflow:visible'. All current browsers properly handle 'overflow:visible' on inline elements, and last I checked MSIE had 'overflow:visibile' as the default for inline elements. 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. +1. -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
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 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) 1a 1a David
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 10:40 AM, Chris Lilley 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
On Thu, Jun 26, 2014 at 6:48 PM, Tab Atkins Jr. 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, , 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 9:44 AM, Anne van Kesteren wrote: > On Thu, Jun 26, 2014 at 6:35 PM, Tab Atkins Jr. 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 clipped though? Ugh, yeah, 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:35 PM, Tab Atkins Jr. 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 clipped though? -- http://annevankesteren.nl/
Re: [whatwg] SVG cloning elements from HTML5
On Thu, Jun 26, 2014 at 9:11 AM, Ian Hickson wrote: > On Tue, 24 Jun 2014, Robert O'Callahan wrote: >> >> >> >> >> >> the elements "s" and "i" are put in the HTML namespace already. > > As siblings of the element, though, not descendants. > > This was required to get some level of compatibility with deployed content > while still allowing in HTML. There was content out there that, for > reasons that defeat me, had 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 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 Tue, 24 Jun 2014, Robert O'Callahan wrote: > > > > > > the elements "s" and "i" are put in the HTML namespace already. As siblings of the element, though, not descendants. This was required to get some level of compatibility with deployed content while still allowing in HTML. There was content out there that, for reasons that defeat me, had 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 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 Tue, Jun 24, 2014 at 9:50 PM, Tab Atkins Jr. wrote: > 1. Define that the SVG layout model is a thing. Yes, this. And also that the layout attributes act are "presentational hints" as per HTML's rendering section. That will explain the cascade effects we want. And then given enough iterations and progress you can display a as a polygon. -- http://annevankesteren.nl/
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 wrote: > On 24 Jun 2014, at 05:25, Robert O'Callahan wrote: >> On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. >> 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. elements trigger it automatically, probably via "display-inside: svg !important;" in the UA stylesheet. (This allows "display: whatever;" on 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 Mon, Jun 23, 2014 at 9:35 PM, Dirk Schulze wrote: > On Jun 24, 2014, at 5:25 AM, Robert O'Callahan wrote: >> On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. >> 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 >> >> >> >> >> 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 was my plan as well. ~TJ
Re: [whatwg] SVG cloning elements from HTML5
On Jun 24, 2014, at 5:25 AM, Robert O'Callahan wrote: > On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. > 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 > > > > > 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 Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. 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 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.r"t 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 18, 2014 6:00 AM, "Robert O'Callahan" 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 . 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
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
[whatwg] SVG cloning elements from HTML5
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 . We should make sure the parser can handle that too, at least for a whitelisted set of elements. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t 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
