4 ms·

How would you implement class selectors and filter features in this XML based styling language.

optymizer 14y ago
I'm not entirely sure what you're referring to as "class selectors". If it's the ability to select elements based on the value of the 'style' attribute, then it would be something along the lines of: //book[@style='someclass'] If that's the case, then that's not what I'd want to do, if I could improve things (even though it would still be possible to do so). Here, the model is coupled with the style, because your model refers to a 'class'. Why would it refer to a class in the presentation? It's essentially saying: "render me this way". Your model should worry about the data, not the style. Why not decouple them, by letting the stylesheet select elements in the model, not the other way around? //book[filter by some property or id] Presumably, if there's a class for a <book>, then there's something that makes that <book> different from other elements, which warranted a different style class. In that case, instead of assigning a 'class', just assign an ID or use some other attributes (or child elements) to figure out the uniqueness. If by 'class selectors' you're referring to the collection of styling attributes and the way those would be filtered and overridden, then you could define something like: <axr:style id='style1'> <color>#ff0</color> <background color="purple"/> </axr:style> <axr:style> <axr:include ref='style1'/> <color>#000</color>  </axr:style> Filtering/overriding qualities are similar to XSL's xsl:import / xsl:include. The @ref could be @href instead, and could refer to elements in other documents (a-la XPointer/XInclude): <axr:include href="../foo.axr#style1"/> Clearly, this requires more thought than I've given it while writing the comment, but I hope this is what you were asking about.
- matzipan 14y ago
  This seems a pretty interesting idea indeed.

I'm not entirely sure what you're referring to as "class selectors". If it's the ability to select elements based on the value of the 'style' attribute, then it would be something along the lines of: //book[@style='someclass'] If that's the case, then that's not what I'd want to do, if I could improve things (even though it would still be possible to do so). Here, the model is coupled with the style, because your model refers to a 'class'. Why would it refer to a class in the presentation? It's essentially saying: "render me this way". Your model should worry about the data, not the style. Why not decouple them, by letting the stylesheet select elements in the model, not the other way around? //book[filter by some property or id] Presumably, if there's a class for a <book>, then there's something that makes that <book> different from other elements, which warranted a different style class. In that case, instead of assigning a 'class', just assign an ID or use some other attributes (or child elements) to figure out the uniqueness. If by 'class selectors' you're referring to the collection of styling attributes and the way those would be filtered and overridden, then you could define something like: <axr:style id='style1'> <color>#ff0</color> <background color="purple"/> </axr:style> <axr:style> <axr:include ref='style1'/> <color>#000</color>  </axr:style> Filtering/overriding qualities are similar to XSL's xsl:import / xsl:include. The @ref could be @href instead, and could refer to elements in other documents (a-la XPointer/XInclude): <axr:include href="../foo.axr#style1"/> Clearly, this requires more thought than I've given it while writing the comment, but I hope this is what you were asking about.

matzipan 14y ago
This seems a pretty interesting idea indeed.