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
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
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
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 absp
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 "t
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 anythi
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 fo
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 lay
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?
--
htt
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 compatibili
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
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
[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 i
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 unfortuna
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
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 fir
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 k
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 t
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 attrib
19 matches
Mail list logo
