Re: transform as a presentation attribute

On Jun 26, 2014, at 11:48 AM, Juergen Roethig <roethig@dhbw-karlsruhe.de> wrote:

> Hello again,
> 
> Am 26.06.2014 10:53, schrieb Dirk Schulze:
>> 
>> On Jun 26, 2014, at 9:39 AM, Juergen Roethig <roethig@dhbw-karlsruhe.de> wrote:
>> 
>>> Am 24.06.2014 23:44, schrieb Tab Atkins Jr.:
>>>> [...]
>>>> 
>>>> <!DOCTYPE html>
>>>> <svg viewBox="0 0 10 10" width=100 height=100 style="border: thin solid;">
>>>>  <rect x=1 y=1 width=2   height=2   fill=blue ></rect>
>>>>  <rect x=1 y=5 width=2px height=2px fill=green></rect>
>>>> </svg>
>>>> 
>>>> [...]
>>> 
>>> Just a question: Is this really the way we should code SVG in the future, or even in the present? As in the past, it looked somewhat different (DOCTYPE, attributes, ...) ... especially the <!DOCTYPE html> concernes me somehow.
>> 
>> This effectively makes the SVG file an HTML file and Tab used it to paste a complete and applicable example that works out of the box without defining namespaces and so on. Inline SVG is definitely important for the future and present. It is still up to you how you want to create your SVG file… the context is very important as well.
> 
> But nevertheless, for this original HTML5-based inline SVG code, there is still an issue which is unclear to me: May you write an HTML5 file (with its "<!DOCTYPE html>") and have _no_ root tag "_<html>_" _but_ _another_ _one_ ("<svg>" in that case)? Well, I am not quite sure about those down-watered grammar rules in HTML5, but does HTML5 allow a DOCTYPE where the first argument (the "html") does no longer give the name of the root tag?

This is part of HMTL5’s recovery rules. If you open Tab’s example in a developer tool of a browser, you will see that it actually is interpreted as:

<!DOCTYPE html>
<html>
<head></head>
<body><svg viewBox="0 0 10 10" width="100" height="100" style="border: thin solid;">
  <rect x="1" y="1" width="2" height="2" fill="blue"></rect>
  <rect x="1" y="5" width="2px" height="2px" fill="green"></rect>
</svg></body>
</html>

> 
> Sorry for the repetition of the question on that list, but I am afraid that on any HTML5 list, they might get shocked about my antique and restricting opinions. And since this might offer the ability to forget about all those restricting grammar issues of current SVG, it will give us (the "SVG experts") finally the freedom to code our applications without all those burdening restrictions when just coding our SVG as an implicit HTML5 by just replacing the DOCTYPE and nothing else, if the answer to the above question is "yes" ... and if the answer is "no", we should probably make it a proposal ;-)

The answer is yes, but… HTML will “add” the missing namespace definitions for you. However, the document is parsed by the HTML parser and the parsing rules are different than the rules of XML. This has consequences for the character encoding and key features from XML like entities that don’t work anymore.

We had proposals to switch to the HTML parser for standalone SVG documents. The vast majority of documents will still work. The relaxed parsing rules will actually make many previously broken SVGs work as well. Decoding will still be different. Wrong unicode descriptions don’t result in an parsing error anymore. Entities won’t be supported anymore. Xlink, XSLT and so on would not be supported natively anymore.

Greetings,
Dirk 

> 
> Best regards,
> 
> Juergen Roethig
> 
>

Received on Thursday, 26 June 2014 11:32:50 UTC