5 ms·
Instead of creating yet another way of defining a tree structure (HSS), why not do this: use XML instead of CSS syntax and XPath instead of CSS selectors and j
by optymizer 14y ago
Instead of creating yet another way of defining a tree structure (HSS), why not do this:
use XML instead of CSS syntax and XPath instead of CSS selectors and just make it less obnoxious than XSL-FO and less template-oriented than XSL:
<!-- index.xml -->
<books>
<book>...</book>
<book>...</book>
</books>
<!-- index.style -->
<axr:style select="//book">
<color>#000</color>
<background color="red"/>
</axr:style>
You can still have your hierarchy, if you prefer, instead of the 'select' above:
<!-- index.style -->
<books>
<book>
<axr:color>#000</axr:color>
<axr:background color="red"/>
</book>
</books>
See? No need for an HSS parser. That's really what "reinventing the wheel" warns against.
Note: I'm generally in favor of rewriting things, when the benefits are clear. With HSS, I don't see why I'd want to replicate the tree again,(using a different syntax, i won't even be able to copy-paste!) just for the style. I'd rather use XPath selectors and XML.
Some thoughts:
1. It would be nice to merge CSS with XML (as others have said - there is really no need to have 2 different syntaxes)
2. It would be nice to use XML everywhere (the more you use it, the easier it's going to be to integrate this into IDEs, scripts, web apps, etc).
3. The important thing is the value of the COLOR, not the fact that you managed to parse braces, pipes, etc and come up with your own syntax for representing a tree and selecting elements in it? That's wasted effort and you're not innovating. Use XML, or JSON, or YAML (whatever floats your boat), but use that EVERYWHERE: for data and style. That would be a step forward from HTML/CSS.
4. Again, there is no need to reinvent XPath, like CSS selectors are trying to do. Use XPath, it works great with XML, it's CONCISE and it is familiar and simple, because it looks like a file path (or basic url) with some optional filtering on each level. (N.B.: don't fall in the XPath2/XQuery trap).
5. Embedding Javascript would be easy: it would be the same as HTML: <script/>.
6. You get brownie points if you could use JSON for elements, style and scripts. You'd reduce the entire HTML/CSS/JS stack to just JSON:
//index.json
{
books: [ { title:"foo" }, { title:"bar" } ]
}
//index.axr (keep XPath-like syntax for selectors, use HSS-like syntax for style)
{
select:"books[0]/title",
style: {
color:"#ff0",
background: { ... }
}
}
This would allow for some interesting (maybe faster?) interactions between Javascript, style and object model.
Though I think I prefer the XML/XPath stack.
Those were my few cents. Good luck with your project!
- matzipan 14y agoHow would you implement class selectors and filter features in this XML based styling language.
- optymizer 14y agoI'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> <!-- override the 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 agoThis seems a pretty interesting idea indeed.