matplotlib-devel Mailing List for matplotlib

On 21 July 2014 17:40, R Hattersley <rha...@gm...> wrote:
> In the case of two Axes, the CSS version would be:
>
> Axes#axes1 {
> border: 1px solid black;
> }
>
> Axes#axes2 {
> border: 2px dashed green;
> }
>
>
Or if you want to borrow from more advanced selector syntax, you could do
fun stuff like:
Axes:nth-child(odd) {
 border: 1px solid black;
}
Axes:nth-child(even) {
 border: 2px dashed green;
}

On 21 July 2014 14:48, jamesramm <jam...@gm...> wrote:
> You've just noted it: Line2D isn't a CSS selector
CSS doesn't define any particular element names - it just operates on
element names in a document tree. So a standard CSS parser will work just
as well with "line2d { ... }" as it would with "h1 { ... }".
On 21 July 2014 14:48, jamesramm <jam...@gm...> wrote:
> ..likewise, the properties we want to call upon (like linewidth) are not
> CSS attributes.
Agreed - not all properties are standard CSS properties, so I was
suggesting borrowing SVG properties to augment the list. NB. That would
make the property controlling line width be called "stroke-width". But
whatever names we choose, a CSS parser doesn't care what the names are.
But really the issue is not so much about CSS and SVG-styling-properties -
it is whether to use existing standards or not. Clearly I'm in favour of
adopting standards. But perhaps there is another standard set of CSS
styling properties which would be a closer match to matplotlib? Perhaps CSS
is not the answer at all, and something like SLD/SE would be better? (I
suspect not! But there could easily be other technologies I'm not aware of!)
 Axes {
> gid: 'axes1';
> autoscalex_on: True;
> ::ylabel {
> text: 'Y-Axis';
> font-size: 10;
> }
> }
>
> I think this would be easier to parse and slightly clearer to read as it
> can be 'attached' to the artist container it refers to (imagine if there
> were 2 axes in a figure...)
In the case of two Axes, the CSS version would be:
Axes#axes1 {
 border: 1px solid black;
}
Axes#axes2 {
 border: 2px dashed green;
}

As a side note, SVG already has specs which extend css to apply to 2D graphics:
www.w3.org/TR/SVGTiny12/styling.html
so we don't need to entirely re-inventing the wheel.
On Mon, Jul 21, 2014 at 9:48 AM, jamesramm <jam...@gm...> wrote:
> R Hattersley wrote
> I'm not sure what it is about CSS syntax that isn't up to the job. For
> example, SVG works with standard CSS syntax (see
> http://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just have
> a different view of what constitutes CSS vs. HTML/SVG/whatever. The example
> in the SVG spec is:
>
> rect {
> fill: red;
> stroke: blue;
> stroke-width: 3
> }
>
> But if we define the element name for a Line2D instance as "line2d" then CSS
> snippet could just become:
>
> line2d {
> stroke: blue;
> stroke-width: 3
> }
>
> You've just noted it: Line2D isn't a CSS selector..likewise, the properties
> we want to call upon (like linewidth) are not CSS attributes. There are many
> matplotlib properties that don't have an analogous CSS property/attribute
> (that I know of); we might aswell define the mpl properties in our 'CSS'
> subset. So we could base our language on CSS rules, but we need to define
> new tokens. This means writing, or more likely, extending a parser. Not
> huge, but not trivial.
>
> R Hattersley wrote
> The DOM facade could help bridge the gap. For example, a "DOM" instance
> returned by an Axes object could pretend to have "text" element children.
> Styling those would route the style information back to the underlying Axes
> object. For example:
>
> text {
> font-size: 12pt;
> }
>
> axes text.ylabel {
> font-size: 10pt;
> }
>
> This could be one way. Another way that would fit and I quite like is
> similar to what is employed by mapnik/the tilemill, in that we simply have
> nested declaration blocks, e.g:
>
> Axes {
> gid: 'axes1';
> autoscalex_on: True;
> ::ylabel {
> text: 'Y-Axis';
> font-size: 10;
> }
> }
>
> I think this would be easier to parse and slightly clearer to read as it can
> be 'attached' to the artist container it refers to (imagine if there were 2
> axes in a figure...). It is also easy to write in BNF, by just adding
> another option to the Declaration block:
>
> Rule := Selector '{' [Declaration] '}'
>
> Declaration := Attribute':' Value';' | Rule
>
> ...
>
> But...small steps. I would start by introducing something for artist
> primitives and for selectively applying to primitives using the gid
> ________________________________
> View this message in context: Re: MEP26: Artist-level stylesheets
>
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Thomas Caswell
tca...@gm...

R Hattersley wrote
> I'm not sure what it is about CSS syntax that isn't up to the job.
> Forexample, SVG works with standard CSS syntax
> (seehttp://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just
> havea different view of what constitutes CSS vs. HTML/SVG/whatever.The
> example in the SVG spec is:
> rect { fill: red; stroke: blue; stroke-width: 3}
> But if we define the element name for a Line2D instance as "line2d"
> thenCSS snippet could just become:
> line2d { stroke: blue; stroke-width: 3}
You've just noted it: Line2D isn't a CSS selector..likewise, the properties
we want to call upon (like linewidth) are not CSS attributes. There are many
matplotlib properties that don't have an analogous CSS property/attribute
(that I know of); we might aswell define the mpl properties in our 'CSS'
subset.So we could base our language on CSS rules, but we need to define new
tokens. This means writing, or more likely, extending a parser. Not huge,
but not trivial. 
R Hattersley wrote
> The DOM facade could help bridge the gap. For example, a "DOM"
> instancereturned by an Axes object could pretend to have "text" element
> children.Styling those would route the style information back to the
> underlying Axesobject. For example:
> text { font-size: 12pt;}axes text.ylabel { font-size: 10pt;}
This could be one way. Another way that would fit and I quite like is
similar to what is employed by mapnik/the tilemill, in that we simply have
nested declaration blocks, e.g:
 Axes { gid: 'axes1'; autoscalex_on: True; ::ylabel
{ text: 'Y-Axis'; font-size: 10; 
} }
I think this would be easier to parse and slightly clearer to read as it can
be 'attached' to the artist container it refers to (imagine if there were 2
axes in a figure...). It is also easy to write in BNF, by just adding
another option to the Declaration block:
Rule := Selector '{' [Declaration] '}'Declaration := Attribute':' Value';' |
Rule...
But...small steps. I would start by introducing something for artist
primitives and for selectively applying to primitives using the gid 
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP26-Artist-level-stylesheets-tp43664p43673.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On 20 July 2014 14:23, jamesramm <jam...@gm...> wrote:
> We cannot stick with the 'standard' CSS syntax by necessity, simply because
> the standard CSS selectors and properties are defined from HTML and do not
> match with matplotlib.
> I.E we want to select by artist type, which doesn't exist in HTML and use
> properties such as linewidth.
>
I'm not sure what it is about CSS syntax that isn't up to the job. For
example, SVG works with standard CSS syntax (see
http://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just have
a different view of what constitutes CSS vs. HTML/SVG/whatever.
The example in the SVG spec is:
rect {
 fill: red;
 stroke: blue;
 stroke-width: 3
}
But if we define the element name for a Line2D instance as "line2d" then
CSS snippet could just become:
line2d {
 stroke: blue;
 stroke-width: 3
}
Sure, matplotlib doesn't define a genuine DOM, but I understand there is
interest in moving to a model more like that. In which case, perhaps a good
way to proceed in the meantime would be to have artists expose a DOM facade
suitable for styling. (Perhaps even using SVG element conventions?)
NB. matplotlib already uses pyparsing, so it would be pretty
straightforward to knock together a parser for CSS (or whatever subset is
needed). Or there are existing Python CSS parser libraries.
> Qt - Pyside/PyQt ('QSS')
> Mapnik ('CartoCSS')
> PyGal supports stylesheets (don't know much about this library)
>
>
If we don't use CSS then +1 for using some other standard.
> As I say, an alternative could be simply using the ConfigParser
>
>
> Richard Hattersley wrote
> >>
> >> Do you have ideas on how one or more stylesheets would be "attached" to
> a
> >> particular figure, etc?
> >>
> >> Regards,
> >> Richard Hattersley
> >>
>
>
> b) Filtering artists
> Another problem is that we would generally want to treat artists which are
> solely for the construction of the Axes differently to those artists that
> define a plot. I.E we might want to define Line2D as having the colour red,
> but we want lines which compose the Axes to be black or grey.
> My initial proposal is to develop stylesheets for artist primitives only.
> But eventually we will want to style artist containers aswell.
> The problem matplotlib has is that the properties for artist containers are
> not uniform/intuitive.
> It generally has a API where artists which are 'contained' by other artists
> are set by calling properties...e.g. axes.set_ylabel(text = , etc...)
>
The DOM facade could help bridge the gap. For example, a "DOM" instance
returned by an Axes object could pretend to have "text" element children.
Styling those would route the style information back to the underlying Axes
object. For example:
text {
 font-size: 12pt;
}
axes text.ylabel {
 font-size: 10pt;
}
I would imagine setting stylesheets through the axes or figure methods
> (axes.setStyleSheet() or figure.setStyleSheet()). Via figure would require
> being able to differentiate between different axes - i.e. introducing the
> 'container' level syntax I mentioned above.
>
> I would imagine that this would eventually replace rcparams to define the
> default style. I would also like to see the default look of graphs moving
> away from the very dated, 90's style MATLAB appearance!
>
That would be an excellent start. More complicated mechanisms can always be
added later if necessary.
Richard