Re: Scope and range of styles

Hello,

if the HTML5 draft (or another draft not yet applicable for SVG) 
has restrictions about what happens with content of an img 
element and this does not apply for object elements, 
authors needing such external file referencing should simply use object, 
not img - the concept of img was already somehow outdated in HTML4
compared to that of object. Questionable why the the HTML5 draft
introduced a new element embed with a similar poor concept, but no
use case at all. In some areas of HTML5 really look like a continuation
of the unfortunate HTML 3.2, sticking in the last century - not something
useful for today.
And if object has a method to care about privacy, why img does not?
What about the drafts about HttpRequest - intended to gather and sending
information due to scripting without a need to inform the user about this?
If we combine this with WebStorage, this creates huge holes in the
concept of privacy - why to specify/implement such things, but to worry about 
privacy for the img element? 
Mozilla worries about declarative interactivity without scripting in SVG dure
to security holes in HTML5 form features, but does not worry, if script 
interpretation is activated - obviously the idea is, that people with
activated script interpretation do not care about privacy anyway,  but people
with script interpretation switched off may care?
All this sounds like a crude concept of privacy in current viewers/efforts of
the W3C - would be better to rethink this concept, if there is one at all,
than to obfuscate existing recommendations ;o)  
If HTML5 does not manage such issues of this format, 
it is obviously not ready to become a recommendation...

Obviously, both the (X)HTML file and the embedded SVG file can reference
the same (alternate) stylesheets.
The main problem occurs here by switching between styling alternatives.
Most viewers will not switch automatically to an alternative style with the
same name in a referenced file, some do not at all allow to switch to
alternative styles - for me this is the core problem here, but these are more
implementation gaps, no specification problems in SVG.

To apply styling from the embedding file to a standalone embedded 
file seems to be a very bad idea, this would be a feature following
the 'principle of most surprise' for skillful/informed authors - and might 
result in a lot of nonsense presentation, especially if we take into account
the idea for SVG 2 to convert lot of attributes to properties together with
the typical viewer problem, not to care about format version indications in
documents.
Soon this can turn in a feature of 'most surprise' for the whole audience.  


Olaf

Received on Friday, 26 September 2014 10:11:02 UTC