I have concerns about placing big inline SVG vectors into html. Does this affect search engines and page rank? Corresponding to what you can lastly hear about Code to Text ratio. I believe inline SVG files should be treated like single line <img /> but I'm affraid it is not. Can anyone have some relevant knowledge how these are treated?
Of course the purpose i need place them inline is animation and styling directly by root css file.
I honestly dont think that this will harm you in the Search Rankings. Search engines would encourage the use of SVG over alternatives such as Canvas.
Google specifically indexes SVG, weather it is stand-alone or embedded into your HTML.
You can find a full list of file types indexable by Google Here
Here is a demo SVG file. Please use Firefox for viewing because currently it seems to be the only properly showing browser.
The task is to construct a pure SVG document (e.g. not html-embedded) that will be able to show tooltips using only CSS features (no JS and also no :before/:after pseudo-elements). I managed to achieve this by using the HTML foreignObject element.
However, I can not find if it is possible to position such elements in relation (e.g. 10px to the left and top from it) to other in-document SVG objects without using JavaScript for it and without embedding the SVG file itself into some other document format (e.g. HTML).
In the final version of the file there will be 20-30+ tooltips, so it is desirable to avoid manual positioning. I was hoping there would be something for "attaching" them to other objects (withthe use of their IDs) or at least to their parent objects, but my search results only return documentation and questions regarding JS or HTML implementations.
add. notes:
1) CSS-only SVG file is required because the file is intended to be used on wiki sites, which prohibid SVGs that have javascript in them.
2) If I understand correctly, displaying HTML formatting in HTML foreignObject element is not a current SVG standard requirement for SVG user agents (i.a. web-browsers). However, Firefox seems to properly display them, and I’d rather use that (even not fully supported) opportunity. If I am missing some easier ways of achieving the same thing — please do tell about them.
3) SVG code backup: pastebin.
Unfortunately, you can't achieve this effect using just CSS because positions in SVG are attributes, not styles.
I'm wondering if I can create multiple "brushes" in a single SVG file and use them thoughout my CSS.
Right now I have a single SVG file that has a gradient stored in the "defs" and a single rectangle that draws it. Then I use this SVG file as a background image in my CSS. It works well but I'd rather not have a million separate SVG files. I'd like to combine like "brushes" together in a single SVG file something like CSS sprites or XAML is capable of.
Is there a way to do this? If so what's the syntax to specify for the CSS background image which SVG element from the svg file to use?
Thanks for any help.
In theory yes, that should be possible. It's not yet fully defined in a w3c spec though and the implementations do differ at this stage.
Note that svg itself allows a special fragment syntax, so in theory you should be able to link to different views of the same svg file. That could be used to do CSS/SVG sprites.
Linking directly to the id of a nested svg fragment (or to any other element inside the svg) is something that would need to be further specified.
Assuming that linking with fragments from a CSS background property works, then a possibility if you use XHTML (serving the resulting file as application/xhtml+xml) is to just include the svg resources inline in the main document, eliminating the need for many separate files. This can be done as a pre-publishing buildstep if you wish to keep the svgs separate for editing. Another possibility is to use data uris.
I'm also seeking for the same, and here are the pointers I could find:
17.3 Linking into SVG content: IRI fragments and SVG views (w3.org)
SVG Stacks (simurai.com)
Can I use SVG fragment identifiers? (caniuse.com)
Better SVG Sprites With Fragment Identifiers (broken-links.com)
According to caniuse.com, there is an issue with browser support, but that does not prevent you to try and observe future browser evolution (in the hope a future day they will all support this obvious feature).
What kind of language is CSS?
My first inclination was to call it a markup language... but it doesn't really fit the mold:
A markup language is a system for
annotating a text in a way which is
syntactically distinguishable from
that text. -wikipedia
CSS uses various selectors to apply properties to elements within HTML, a markup language
I would say it is a domain-specific declarative language.
Syntactically, CSS is a mix of two languages: the language of selectors, which is a pattern-matching one, like regexps or xpath, and the language of properties, which can be classified as "procedural-declarative", because properties are essentially assignment operators. At a subjective level, css clearly qualifies as ugly mess, like pretty much every other fruit of collective efforts on the field of language design ("a camel is a horse designed by committee").
CSS is not really a language, per se; it is more of a syntax for describing configuration directives.
In fact, it is neither of these things; CSS is a description of a number of tokens and their visual meanings; .css files contain these tokens structured in manner allowing a computer to parse them. CSS declarations can take the form of name="value" declarations in SVG documents; and the .css file structure could just as easily be employed to, say, contain unit descriptions in a particularly absurd iteration of FreeCiv.
Wikipedias definition of it as a Style sheet language seems like a bit of a forced definition of a generalization of a singularly existing phenomenon; and it should be clear that it is not in any way a markup language, as it doesn't actually, by itself, mark anything up.
CSS is most definitely a language:
Wikipedia refers to css as a 'style sheet language'
http://en.wikipedia.org/wiki/Style_sheet_language
Also from W3C who developed CSS: (comparing xsl and css)
The unique features are that CSS can be used to style HTML & XML documents. XSL, on the other hand, is able to transform documents. For example, XSL can be used to transform XML data into HTML/CSS documents on the Web server. This way, the two languages complement each other and can be used together.
Both languages can be used to style XML documents.
As you can see from the second sentence W3C refers to CSS as a language.
http://www.w3.org/Style/
And the next quote again from the same article:
The fact that W3C has developed XSL in addition to CSS has caused some confusion. Why develop a second style sheet language when implementers haven't even finished the first one? The answer can be found in the table below:
CSS XSL
Can be used with HTML? yes no
Can be used with XML? yes yes
Transformation language? no yes
Syntax CSS XML
CSS has a well-defined grammar, thus it is a language, and if you had to choose between CSS being declarative or imperative, then it would be declarative, as the results of its operation are determined by the program actually interpreting and processing the CSS.
However, you can't build anything useful with CSS alone; it needs a document to operate on, and all the CSS does is provide supplemental information for the document; effectively, then, the CCS is a part of the document it operates on.
The problem with CSS is that is it used as part of the HTML to DOM generation process; therefore CSS behaves similar to "messy" global variables, and as a result, developers have to deal with the plethora of nasty side effects CSS brings along with it.
Hopefully, Håkon Wium Lie, the inventor of CSS, and a major player at the W3C will one day come to realize that CSS was and is a mistake from the beginning until today and the wrong path to take to achieve a separation of semantic markup and presentation.
Today, CCS is gaining imperative features with #media queries, and targeting with #operators, such as #screen and #print. But none of the new features will correct the fundamentals flaws of CSS: the god-awful globals, and the notorious unreasonable use of side-effects with its element selectors.
Unfortunately, the study of CSS as a language is more complex than the study of real programming languages, as examples of how to use it are more anecdotal than practical, hence the need for comprehensive CSS frameworks like Bootstrap and others to get your job done.
What should be written first while making CSS layouts XHTML code or CSS code?
Write Whole HTML first then write
CSS according to HTML
Write HTML for an design element and
CSS simultaneously
Write whole CSS first then write
HTML according to HTML
I read on this article's point # 7 "Create Your HTML First" is this advice best to follow?
Edit:
and in this tutorial author also write HTML First then write css using Edit CSS option of web developer toolbar i think this is best way.
In practice, you generally wind up needing to intermingle the two. Start out with HTML to rough out the basic areas of your design, then work in CSS around that rough idea. Typically you'll find yourself needing to add some more markup to allow for additional flexibility (perhaps you need a couple of nested containers to properly align something, et cetera).
I used to ponder about this long ago, when designing websites.
My conclusion was, and I believe it still stands today, that even though XHTML and CSS are meant to be isolated from each other as content and presentation respectively, the reality of the matter still makes the look of the website pretty much depend on the document structure - i.e. markup, XHTML - and thus CSS alone will not give you the magic wand to make your website change its look completely based on a stylesheet. I wish it were so however - certainly, that is the main purpose of CSS. And certainly, that would be the beauty of it - since each is completely isolated from the other, website developers can in peace of mind program the structure of the website documents, almost while the CSS authors can work in parallel and write the stylesheets. Then both are combined, and with the knowledge that the markup does not need to be changed ever again. That is the theory anyway.
In practice this often fails to work - because a document has a top-to-bottom left-to-right (usually) bound semantics, it becomes difficult to for instance, make an element appearing at the bottom of the document structure, appear at the top of the browser page to the user. The limitations work against the theory.
Because of the above implications, and some other real-world limitations of the CSS and markup technologies, I have decided to simply consider markup as something in between the content and the style. I.e. some of the markup will unfortunately dictate style, no matter stylesheet - the sequence of elements being one (see above), pagination limitations, etc - and so, while most of the structure may be isolated from its appearance, some of this appearance will be dictated by it. For this reason, if we don't regard client side scripting (which may aid styling by re-arranging elements of a document) - one way to do it is use XML as content, XHTML as content-style hybrid layer, and CSS to finally dictate the appearance.
Where does XML come into this? Well, you transform (either in browser or server-side) it with XSLT into a XHTML document, which you consider as relevant in the styling process. I.e. if you have an artist list of 1000 entries, and you want to customize how the page looks like, you use the following content XML:
<artists>
<artist name="Moby" />
<artist name="Cocorosie" />
<!-- and so on -->
</artists>
This is considered as an unchanging content, no matter the final style - part of the point of separating content from presentation, something you could not have done fully with XHTML because CSS cannot do certain things. With XSLT however, you can further transform the above into a desired markup ( you can then apply CSS to):
<xsl:transform>
<!-- XSLT is beyond the scope of this... -->
</xsl:transform>
will transform the XML into something like:
<h1>Artists</h1>
<h2>Page 1 of 10</h1>
<ul>
<li><a>Moby</a></li>
<!-- Only 100 artists per page -->
</ul>
And then you style it.
Bottomline is, you get to control each point of the transformation of your raw database content into final end-user application.
Much of what XSLT does with XML, can be instead done with JavaScript on XHTML, but I consider client-side scripting an addition, not replacement to things like XSLT. Then again, Firefox and most other modern browsers can do XSLT client-side, which blurs the distinction between scripting and document serving.
I think it's a mistake to do one before the other. Programming is an iterative process. Write them both until you have something small that works, then do it again. Build on it. Iterate.
If you write just HTML without writing any CSS, you'll find out later that you'll have a bunch of technical debt that needs to be paid off.
It really depends how big is your site... If it's a small website the order doesn't matter. If it's a big website i generally design basic structure in HTML then basic CSS and then move to details in HTML and then CSS.
Few advices.
re-use already made CSS and HTML.
ie. if you already have template
with basic HTML wrappers save it
for the next project or page or
if you set all images to
border:none in your CSS you can
easily save some CSS file with
basic settings
see an object in your head before
designing it
check in 5 major browsers (ie6 ie7
ie8 chrome and firefox)
I usually go with the second option:
Write HTML for an design element and
CSS simultaneously
This really helps, for example, when I am writing html, i write the CSS along the way too which helps me quickly spot any possible layout or cross-browser compatibility issues. If i wrote whole html first and then css, then things become little complicated and you have hard time correcting/styling the entire html which you already created.
As for the link you provided, i would simply say author has his own view and personal way of working. In other words, this also depends which way you are most comfortable with or rather fast.
You can't write CSS before writing the HTML (except for the body tag!), or you'll be working like a blind.
For me, I make a mock-up of the website layout, write down the whole HTML and then write CSS that just makes the layout.
I use Expression design to slice images and add/modify HTML/CSS until I get the final template.
I don't like the idea of going back and forth with code. If I'm at #header in html, it seems pretty logical to me to stylize the header right now. Is good for my mental sanity :D
So I go with the second option: I wrote code simultaneously.
You have to write HTML before CSS.
Your question is like, Is it better to design a car Interior, before having a car ?
Is it possible ? or Is it a intelligent work ?
Given that most designs are not simple, and following basic semantical rules, you will always need to adjust the html code when trying to get the layout looking as you have in mind. So doing both simultaneously is probably the most pratical way, although the other two options work as well; You just need to made adjustments then later.
Sorry , I am not choosing anyone of these..
In first you can't able to write the whole css for your page. although it's better you should write the common css classes and page layouts in the first.ie, after creating the page layout , you just design the page using table or div tags. after , while adding controls to the pages , you just identify the common styles u are using. These styles you can use like css classes. or seperate id. I am following this method for my designing.
i think its better.
By creating the HTML first, you can guarantee what the page will look like on the most basic browsers - it'll be legible on an old phone, everything's in logical order, and you aren't forcing screen readers to recite your site navigation first thing on every single page. That's design #1.
Design #2 is the CSS part, where you actually make things look visibly decent without limiting your user base.
Not that they can't be done simultaneously, mind. Just that's most likely what the author of that article was trying to get at.
See also: Progressive Enhancement.
I personally write much of the CSS first, then HTML, then tweak the two together - one page at a time (apart from common elements). At first it sounds counter-intuitive, but when you think of the CSS as not only styles but as elements that either have a style or have a style of nothing, it's actually very fast and produces lean code.
Once I've got some core styles in place, the HTML is just a question of...
<wrapper>
<div header>
<div this>
<div that>
<form>
<div footer>
... and it all slots roughly into the styles and layout that I've already defined. For elements that needed no styling, I just mentally skipped over when writing the CSS.
My 3 cents:
What's the goal of the webpage? Most of the time that goal is strongly related to it's content.
Thus, the first thing is content. HTML gives content gets it's semantics. CSS gives the semantics a context.
So the order:
content
html
css
But of course, it's an iterative process.
I write them at the same time, iteratively, in modules.
I will build out the general template (or base template) in html/css, do a full cross-browser test, then move on to the additional templates.
This fits in well with .net where I'm using master pages and nested master pages.
I may change this behaviour once IE6 is off the books, as you often have to completely restructure your markup to accommodate it.
I'd go with the second option. HTML in todays web dev is seen as a template to hold content. CSS should be used to format the layout and content within the web page.
Because of this, HTML and CSS should be used parallel in creating web-pages and individual elements.