I was trying different solutions to use #media in css (or to be more precise, sass) and was thinking about the way we commonly use #media. The most common way, at least that I know and I see on blog posts, tutorials, etc.. Is to define some standard values and then we use them. For example:
$small: 420px;
$medium: 768px;
$large: 992px;
$extra-large: 1200px;
#media screen and (min-width: $medium) { ... }
#media screen and (min-width: $large) { ... }
The problem I'm facing with this approach is that my menu doesn't fit well any of the predefined values. So when it break the media size, it gets a huge blank space, even thought there is still space to fit the menu. In this case I could break it at 780px but the values are 768 or 992.
So my question is.. Is it okay to approach media queries this way and break the media based on content by defining the values manually?
The menu would be 780px, let's say that a grid that I display the company members would break at 820px and 540px. Each of them I would need to analyse it visually on the browser, measure and set the value manually.
I would still use (if there's not a better way) the pre defined values for common elements on the page (if needed). There is this article that I like a lot (a little out of date but a good concept), it covers the screen size usage and how to group them. But it doesn't approach the issue I'm questioning here.
Also, other big companies, like Airbnb, Spotify, Github they use predefined values to break the #media content. All based on predefined values, not the content. Spotify is one example. The menu breaks too soon, even with enough space to keep the items before moving to aside off screen.
--
The only reason I can think of to keep using this method is because we, as end users, are so used to have a menu toggle on the top header that it doesn't matter if there is enough space to keep the inline text. Since we are used to the button to open the menu, we use this technique, hence the use of pre defined media values.
Related
How can I make InDesign render a region of a page, as it would be rendered when exporting the whole file?
I know I can render a PageItem using the exportFile function, but this will ignore any other PageItems sharing the same region.
My current solution is to make a new document the size of the region of interest, with a copy of each PageItem whose coordinates fall into that region. It’s very inelegant, and it seems it cannot be done without the user seeing windows meaningless to them come and go.
Another approach I can think of is to export the whole spread containing the region, then crop the resulting file using something like ImageMagick. But I’d still prefer to be able to render only the region I need, if possible.
You can open the InDesing document without showing its UI as well.
app.open(filepath, false);
and while closing the doc, simple use
doc.close(SaveOptions.NO);
You anyways don't need to save that doc on disk.
This will let you have the document open without showing its UI at all.
I did something like this recently. Here are my steps:
duplicate all spread items and group them
make a frame with a proper size/position
cut and paste the group into this frame
export the frame as PNG
If you need another region on this spread you don't need to repeat all the steps, you can change size and position of the frame and to export it again.
There is a limitation: master page items will be omitted.
I am currently trying to jazz up a SilverStripe site by making the content more engaging. The site is responsive, but all this means currently is that the navigation bar/header snaps to a more mobile friendly style when it hits the mobile break point.
The long and short of it is, my main page.ss is this:
<html>
<head>
<title>$Title</title>
</head>
<body>
$Header
$Layout
$Footer
</body>
</html>
With $Layout rendering a few variations of a basic page. We have a couple of layouts that aim to give our webmaster pages that are a bit more engaging - for example we have an accordion type page that has many accordion section DataObjects, that present the page as an accordion page with the open/shut javascript functionality.
But this is not enough. I want to give the webmaster more flexibility in the CMS to create interesting pages, without me having to create hundreds of different page types.
I'm thinking of creating a module that gets rid of the main $Content field for all pages, and instead inserts a sort of grid system management field. The webmaster can add rows (one DataObject) and then split those rows into sections (another DataObject). The sections will have a content field managed by TinyMCE, just like a page has. Then on the front end I will map these rows and sections to a responsive grid system.
For variations on the sections, I will add classes (a bit like having different page types) that render slightly differently. The sections will have .ss and .css (and possibly .js) to control their own look and feel.
My question is, how have other people approached this problem? Does my idea sound like overkill? Or does it sound like a good idea for a module?
-
For some examples of what I am trying to achieve, this page is a good example:
http://www.wingsforlife.com/en/research/
Content is split up into various sections, which allows for better control when the page is resized. Also throughout the site, content is varied, sometimes it will be in a single column, other times two, which snaps to one column when the window is smaller.
On the home page, if you scroll down, there are 4 links that are presented inside circles, that contain a number and some text: http://www.wingsforlife.com/en/
This is something I can't see being possible inside TinyMCE (which is fair enough as TinyMCE is just a basic content editor, not a web design tool).
Have a look at https://github.com/burnbright/silverstripe-widgetpages for an implementation of using Widgets to compose a webpage. Also https://github.com/g4b0/silverstripe-widget-pages-extension.
this can easily be achieved by replacing the HTMLEditorField that's linked to the Content field in the database by some GridField, managing DataObjects that make up what you might call 'ContentParts'. we've already used this approach in some projects to allow for more rendering flexibility of content elements.
simply tie some DataObjects to your Page class:
private static $has_many = array(
'ContentParts' => 'ContentPart'
);
then, use a GridField to manage them in your getCMSFields:
$gridFieldConfig = GridFieldConfig_RecordEditor::create();
$field_ContentParts = new GridField('ContentParts', 'Content Parts', $this->ContentParts(), $gridFieldConfig);
simplest way to render them in your template is as follows:
<% loop ContentParts %>
<section>...</section>
<% end_loop %>
of course you'll want to have different contentparts, so you might want to create subclasses of ContentPart with their custom fields and use the GridFieldAddNewMultiClass component to add them to your GridField (it's part of the GridFieldExtensions module, to be found here: https://github.com/ajshort/silverstripe-gridfieldextensions)
hth
what would it take to allow media queries through HTMLPurifier + CSStidy?
In other words, I am using these libraries:
require_once 'inc_php_classes/htmlpurifier-4_4_0/library/HTMLPurifier.auto.php';
require_once 'inc_php_classes/csstidy-1_3/class.csstidy.php';
...to sanitize admin-user input before I save it to database.. for populating an external style sheet ... and so it happens that any input media queries are getting munged.. e.g. this:
#media only screen and (min-width: 600px) and (max-width: 939px) {
becomes
#media only screen and min-width 600px and max-width 939px {
..which breaks the media query, at least in Chrome 18/Mac.
The form/input is used for creating custom style sheets for trusted admin users.. and they need media queries.. but even though they are trusted, I do not want to just drop use of CSStidy.. because of the off chance an admin goes AWOL, not to mention I want to clean their newbie CSS errors.
Not sure, it's definitely not supported by vanilla HTML Purifier. It is reasonably plausible that CSSTidy does parse media selectors properly, so it's just a matter of teaching HTML Purifire not to strip them out.
How do I define multiple media queries in one file?
I have this .styl-file:
#media (min-width: 980px)
body
padding-top 60px
#media (min-width: 768px)
body
.container
width 768px
This is giving me the error expected "indent", got "newline". Placing them in separate files and having one file include the other works. But when I have them in the same file and a second file that is importing this one it fails.
Update: The code of the files can be found here:
https://github.com/mastoj/NodeJsExpressFun/blob/master/public/stylesheets/style.styl
https://github.com/mastoj/NodeJsExpressFun/blob/master/public/stylesheets/nblog.styl
Your problem is that you have tabs in the top query, and spaces in the lower. Try to be consistent (this is a good practice in general, when it comes to all kinds of programming). I don't have a preference either way, but you should probably look into your editor settings to see if you can enforce consistency on that level. My editor puts 4 or 2 spaces when I press tab, depending on language.
Your example in the question works, actually (there's only spaces in that one).
I have a clutter texture as my background . I need to put some clutter actors over it. is it possible to do it . Since i get the following error:
"invalid cast from `ClutterTexture' to `ClutterContainer' "
Can any one help me ?
ClutterTexture is not a container, i.e. it cannot contain other actors.
ClutterBox and ClutterGroup are containers available in Clutter; ClutterBox allows using different layout managers - like ClutterBinLayout:
http://developer.gnome.org/clutter/stable/ClutterBinLayout.html
or ClutterFixedLayout:
http://developer.gnome.org/clutter/stable/ClutterFixedLayout.html
you can also use ClutterGroup, and use constraints to maintain a layout:
http://developer.gnome.org/clutter/stable/ClutterConstraint.html
It has been a while since I have used clutter but I will try to provide some insights. As the error says you cannot cast ClutterTexture to ClutterContainer. You can add actors only to container actors. If you want to setup background one of the options could be stacking of actors. You can stack other actors on top of the actor with background texture using layout managers. This link provides some details which I think can be useful in your case.
Hope this helps!