Support string stylesheets
See original GitHub issueIn addition to the JSON format used for specifying stylesheets, allow for string stylesheets formatted like CSS.
e.g.
node {
height: 10
}
becomes
{
'selector': 'node',
'css': {
'height': 10
}
}
etc.
Issue Analytics
- State:
- Created 10 years ago
- Comments:10 (6 by maintainers)
Top Results From Across the Web
<string> - CSS: Cascading Style Sheets - MDN Web Docs
The <string> CSS data type represents a sequence of characters. Strings are used in numerous CSS properties, such as content , font-family ...
Read more >css - In JavaFX 8 can I provide a stylesheet from a String?
Style sheets are loaded from the URLs specified in the stylesheets variable of the Scene object.
Read more >Strings - Sass
Sass supports two kinds of strings whose internal structure is the same but which are rendered differently: quoted strings, like "Helvetica Neue" ,...
Read more >JavaScript String toString() Method - W3Schools
Well organized and easy to understand Web building tutorials with lots of examples of how to use HTML, CSS, JavaScript, SQL, Python, PHP,...
Read more >.css() | jQuery API Documentation
.css( propertyName )Returns: String ... As of jQuery 3.2, CSS Custom Properties (also called CSS Variables) are supported: $( "p" ).css( "--custom-property" ) ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
The mentioned reason for the missing hover is not actually true. Not all touch devices are missing the hover option - in fact several high end devices do have such an option when using a stylus. Just because most of the touch devices are missing this functionality it doesn’t mean that all devices should be punished for that.
It’s the developers job to know that their product might end in an environment that does not support hover and do something about that.
If a dev wants to use hover, he can write a few lines and use a class instead of a state selector. There’s nothing preventing you from using hover if you want.
I can see where you’re going with your argument, but I think it’s actually the opposite: Just because a subset of devices support something, we shouldn’t punish all the remaining devices by depriving them of features by default.
In desktop-only projects, hover may be OK. For other projects, hover is not sufficient. That means that you need to handle touch in some analogous way for your particular app, or it means you need to handle the entire feature in a consistent, device agnostic way without hover at all. Most commonly, devs will do neither if
:hover
is available to them – leaving touch devices without a feature.More often than not, the second option is superior because it offers uniformity. For the first option, I think it’s better to have the dev write a few lines so he can consider touch support as well. Using custom events, those few lines also allow him to generalise a gesture on top of hover for desktop and some other action on touch.