Fix switch & conditional processing

[AmeliaBR]

Master issue for summing up many bugs & discussions. There are separate issues for each, please discuss them there. Use this issue for general discussion on the purpose & potential of the switch element and conditional processing attributes in SVG.

Broken & undefined behavior in SVG 1.1:

• The method of defining extension strings for requiredExtensions was never well defined, and is therefore not as useful as it could be. See issue Define how requiredExtensions values should be interpretted #138.
• The systemLanguage attribute doesn't accommodate users with multiple acceptable (but ranked by preference) languages. See issue Support SMIL allowReorder processing for systemLanguage attribute #136.
• The switch element was allowed to have title and desc content, but these were not explicitly excluded from the switching behavior so end up deactivating the switching process. The resolved solution (for backwards compatibility purposes) is to prohibit title & desc as direct children of switch. Some spec cleanup still required; see issue Clean up language re <title>/<desc> and tooltips #102.
• Impact of switch on non-rendered content was not well defined. See discussion on the mailing list from 2014; current SVG 2 text clarifies the switch does not affect script or style element processing, but clarifications may be required for other element types. See issue Does conditional processing mute sound playback? #44 for conditional processing and audio/video elements.

Formerly working behavior that have been removed in the current draft of SVG 2:

• The requiredFeatures attribute was not very well defined in SVG 1.1, but it was functional for a few use cases (<foreignObject> support, animation element support, basic filter support), and commonly used for them. It and the corresponding Feature String appendix were removed as a (possibly inadvertent?) consequence of the decision to remove the hasFeature method (which browsers had implemented in a manner that wasn't future-focused).

Desired new features (won't happen for SVG 2, but good to keep in mind):

• A media-query conditional processing attribute, to create behavior equivalent to the HTML <picture> element. See issue Support media queries in switch / as a conditional processing attribute #137.
• A way to use CSS variables to create a custom case/switch construct. See issue Parameters and Switch command to allow parametric SVGs #128.

Please add references to other relevant issues here. However, please keep this issue for general overview discussion only.

[nikosandronikos]

Looks like the removal of the requiredFeatures attribute and the appendix was intentional. Apparently implementations are at the point where they always return true.
It happend in 9a30d01 and there's a link to discussion there.

[AmeliaBR]

The issue (as I recall) was that for the hasFeature() JS API, any unfamiliar terms were returning true instead of false, which was not useful. I'm not sure whether anyone tested whether the same problem existed for the declarative format. Either way, this feature was actually being used (e.g., to test for foreignObject support) and simply removing it could break content that used to work. It shouldn't break too badly in a well-designed switch construct, since browsers that implement the change will support most of the things you test for. But not all: what if you were testing SVG font support?

I'm not going to make a huge fuss over it, but it seemed important to mention in the context of "what are we going to do with <switch>?" This feature had real-world uses & we intentionally scrapped it.
I mean, ideally we'd have a much-more fine grained and clearly defined feature testing method, but this was something.

[satakagi]

How about introducing the custom-made conditions supposing chiefly controlling from javascript into a switch element? It can be said to be the even more primitive thing of #128. Of course it will be a story future than SVG2.

<switch id="sw1" customConditionValue="TALL">
 <g customCondition="LARGE">...</g>
 <g customCondition="SMALL">...</g>
 <g customCondition="TALL">...</g>
</switch>

document.getElementById("sw1").setCustomConditionValue("LARGE");

Without javascript, it is only comparison among the customConditionValue attribute value of a switch element, and the customCondition attribute value of child elements.

It is the following reasons that I resulted in this thought.
I have investigated #137 media-query conditional processing attribute. Then, I faced various issues. First of all, such implementation may not be so easy as it discusses within the links of #137.

Furthermore, I have noticed that conditional processing having far complicated conditions is required for realization of Level of Detail which is use case which I have. I thought it premature to describe it declaratively for the moment.

On the other hand, I think that the concept of switch element such as "Choose the child element corresponding to conditions of some kind" will make semantics of contents rich and will improve reusability. So to speak, It is the semantics such as "Aside from some conditions, those child elements can be substituted each other". This is the semantics which is very helpful by searching, reusing etc., at the viewpoint of SVG as data.

I think that such switch element is very useful at least at Mapping apps using SVG which I am developing from a viewpoint of separation of processing and data.

[jarek-foksa]

Is complete deprecation of <switch> still an option? According to Chrome stats it's not really much more popular than SVG Fonts or SMIL.

[AmeliaBR]

@satakagi
I'm not sure how much benefit there is to having a special switch syntax that can only be triggered with JavaScript. If JavaScript is active, there are many options to control rendering (changing classes, or simply removing elements from the DOM). A switch is most useful in declarative contexts where scripting is forbidden.

However, what you say about needing complex author control is true. Issue #128 is a proposal for using CSS variables as a custom switch value which authors could control. That way, the author could use any combination of media queries, classes, or user interaction to define the CSS variable, and the variable would trigger the switch.

[satakagi]

@AmeliaBR
#128 depends on SVG Parameters. It seems that SVG Parameters should be applied to all the web documents rather than a thing applicable only for SVG as that draft specification has declared. Therefore, I am concerned about whether that standardization requires a long time.

On the other hand, I consider that switch has the semantics of choosing one of the child elements, and it is the considerably essential semantics which other container elements do not have. Then, I thought it desirable to define it as not being bound by specific conditions. Besides, such semantics will be hidden by the inside of applications by javascript etc. only by changing of class, or the editing of DOM.

Where, the spec. which surely I showed previously may be too much meaningless without javascript. Then, how about giving such a more meaningful function?

<svg customConditionValue="TALL" .... >
<view id="LARGE" customConditionValue="LARGE"/>
<view id="SMALL" customConditionValue="SMALL"/>

<switch>
 <g customCondition="LARGE">...</g>
 <g customCondition="SMALL">...</g>
 <g customCondition="TALL">...</g>
</switch>
</svg>

It adds the function to set up the conditions for switch, on a view element. customCondition regards it as global conditions. The function to change not only viewBox but the representation itself by a fragmentation identifier is added.

[AmeliaBR]

@satakagi I agree that this would be useful. Perhaps it can be implemented sooner than the entire SVG Parameters proposal, but it should probably be compatible with it. However, there is still too much to discuss to get it into SVG 2.

[Angelk90]

@AmeliaBR , @nikosandronikos, @satakagi, @jarek-foksa: Are there any news?