Why opaque "selectorText"?

[oakad]

CSS selectors are predicates, optionally subject to composition by a number of reasonably well defined operators (as evidenced by the fact that they work roughly the same in different browsers). Would not it make sense, therefore, to actually expand the structure of the selector for serialization purposes, rather than keep it lumped together in a string?

Instead of "body"something to the tune of "body", with selector composition operators having their own element names (apart from comma, which can be kept implicit among siblings).

[danielpeintner]

Hi @oakad ,

The current XML representation is inspired by the CSS Object Model draft [1]. There a selectorText is just a string.

To improve performance and string table likelyhood the selectorText element is described as a list of strings [2]. Hence in EXI the following selector

h1, h2, p {
    text-align: center;
    color: red;
}

would be split in "h1", "h2" and "p".

Having said that, I am not sure what you would propose/improve to do. Can you make an example?

Thanks,

-- Daniel

[1] https://www.w3.org/TR/cssom-1/#dom-cssstylerule-selectortext
[2] https://github.com/EXIficient/exificient-for-css/blob/master/src/main/resources/exi4css.xsd#L76

[oakad]

I meant combined selectors like "div span", "div + p" , "ul > li" and the like. Those also should be split:

1. for exactly the same reason you've just mentioned regarding the comma combinator
2. and also for ease of validation/culling unneeded rules

Thus, selector combinator must be encoded somehow, p.2 being much easier when dealing with the proper xml form.

I came to this from somewhat different direction, though. I was working out a document store concept, and found out that considerable processing efficiencies can be realized from storing a validated and filtered CSS in a separate namespace of the XHTML file it applies to. At this point I was on the verge of developing my own CSS to XML mapping, but found your projects here - and seeing how impressive the EXI is, I intend to go deeper into it.

[danielpeintner]

I see your point and I fully agree.

Do you have an opinion how the resulting XML (or respectively XML schema) for the element selectorText should look like?
At the moment it is just a list of strings which seems to be insufficient.

<xs:element name="selectorText">
    <xs:simpleType>
      <xs:list itemType="xs:string"/>
    </xs:simpleType>
</xs:element>

As far as I can tell there are four different combinators in CSS3:

• descendant selector (space)
• child selector (>)
• adjacent sibling selector (+)
• general sibling selector (~)

And looking at https://www.w3.org/TR/cssom-1/#selectors a proposal could be the following for "div + p"

<selectorText>
    <selector>
        <id>div</id>
        <combinator>+</combinator>
        <id>+</id>
    </selector>
</selectorText>

A selector id/name followed by a list of combinator plus id/name again.

Any thoughts/comments ?

[oakad]

I suppose, the most straightforward way is to use the grammar (https://www.w3.org/TR/css-syntax-3/) to produce an AST, then encode it as EXI (same as you did with EXI-js). That way, the XML representation will be strictly in sync with the spec, and no new language will be introduced.

[danielpeintner]

Sorry for the "silence". I was and still are busy with other stuff.

@oakad if you have a proposal in mind I am happy to take a look at your pull request / proposal!

[oakad]

I want to get to it (across the lines of "css3 standard parse tree" -> xml -> exi), but am held busy by other things as well.