I am passing my .css file through the W3C CSS Validation package on Atom and it gives me a "Parse Error" message virtually to all variables created for the sake of an exercise. Here below there is the beginning of the :root pseudo-class (but all the remaining variable declarations are as just as faulty)
I already tried to re-write them from scratch, replace them or change the values only to check the behaviour, but nothing changes it.
:root {
--primary-color: #781820;
--secondary-color: #ABABAB;
--tertiary-color: #cead00;
--backup-color: #FAFAFA;
...
Other than fixing the errors, I'd like to understand where they lie to better understand the process.
As stated, this is a non-issue. CSS is moving and changing too fast for the Jigsaw W3C CSS validator to keep up, and it can no longer be relied on for checking anything other than the most mature feature sets such as those of CSS2, and of the earliest CSS3 specs.
It's a shame that it can't even be used reliably to check for careless errors now (which is what it's always been intended for) because the real errors are constantly getting occluded by so many of these fake ones. For example, it may not spot a real typo because it was thrown off a few lines up by one of these features it doesn't support.
The most reliable validator these days is to test in browsers and assume that if it works consistently across the board, then it's valid. Or, when in doubt, ask a question here and hope someone familiar with the specs will answer. If anyone asks you if you've tried validating your CSS, point them to me.
Related
Once in a while, a css rule will be ignored, despite being correctly defined in the loaded stylesheet, and correctly targeted at a class patently present in the markup. Has anyone come across this, and can anyone explain what is going on?
You will not be able to reproduce the issue, but consider the following, pasted from markup/scss:
.test-footer {
display: none;
background: red !important;
}
.test-footer {
display: none;
}
<footer class="test-footer"></footer>
The topmost rules did nothing (I added the red !important line just to be sure it wasn't being overridden). Then, without changing anything else, I added the second, identical rule, which was honoured without issue.
I have experienced this a few times now – not so frequently that it has entered my offhand list of things to look for when css misbehaves, but often enough over the last year that I have taken notice.
I am using Coda 2, and working on a mac running OSX El Capitan. Also, I am using the Coda sass plugin to compile.
The behaviour was consistent across browsers, and editing any other part of the stylesheet produced the expected results. As stated above, I checked, and the correct css was there all along – one part of it was simply ignored.
My solution should not work, so why does it? Come to that, the issue should not arise in the first place, so why did it?
Update:
I enabled hidden characters, to see if they might be the culprit, like Ruud Helderman suggested below, but I found nothing. In the end I had to let it lie. I solved my problem, after all, even though the "solution" was a magical fluke, or rather the problem was, and the question was asked as much out of intellectual curiosity as anything else. I am leaving the question unanswered for now, thinking that when and if it occurs again, I will update with any findings.
My only experience that comes anywhere near what you describe, is a syntax error in the stylesheet causing all subsequent rules to be ignored. Rules preceding the faulty rule would still be effective.
Another possibility might be the presence of an invisible character (e.g. U+200B); try to configure your text editor to reveal non-printable characters.
Ok, so this came back in a big way – there was much griping about my perceived failure to pull changes from git, because my colleague's styling changes appeared to be overwritten when I pushed changes to the server. I found that his changes were actually present in the compiled css: they were simply ignored by the browser. I still found nothing amiss in the css – no hidden characters, nothing.
But in this case there were differences in how the scss was written, and also in how we compiled. Specifically, he uses linebreaks weirdly, which shouldn't affect the output, but did. He also uses Coda, by the way, so this makes no sense at all. But the "solution" turned out to be changing the sass output style to "compressed", which is annoying in development, and shouldn't be necessary, as the compiled css was fine all along, but it made the problem go away, and hopefully, this is the end of it.
In CSS Text Decoration Module Level 3, there’s text-decoration-skip. It does magic like this:
This representation is allegedly produced by using text-decoration-skip: ink;. For web typography, it’d be great if descenders are no longer struck through by native underlining.
There’s an entry at CSS-Tricks and more recently also one on MDN. There, it says it’s “not on a standards track”. Is that right? The property is listed in the W3C Candidate Recommendation.
How can I use text-decoration-skip? Or when? Are there flags to enable it?
As someone said in the comments to the question, there's no saying when and how it will be implemented.
For reference anmd clarification, the origin article of the picture you posted isn't what the actual spec necessarily will look like, but a draft of what Marcin Wichary had in mind when tinkering with it. So don't make the mistake and consider that image a reference for the CSS3 output, as it may look entirely different when finally implemented.
I also can't tell you why MDN doesn't list it as a feature necessarily to be implemented, whether it's a decision of the development team not to implement it, or they just missed it. I can, however, tell you that they are correct in saying "This property has not yet been implemented in any modern browser."
As for browser support, take note of this comment in the CSS-Tricks article, linking to the folliowing image:
It's not only interesting because that's quite a dated browser (which of course didn't do this because of some CSS3 spec, but likely because they had the same basic idea), but also because that's likely what the property will look like when finally implemented.
While text-decoration-skip seems to have been “deferred to Level 4 to allow for major changes”, Chrome 64 (2018-01) and Firefox 70 (2019-10) implemented a close relative (applied by default), because “most other browsers are converging on supporting the simpler text-decoration-skip-ink property”, and it certainly does work:
u{font-size:444%;}
u:first-of-type{ text-decoration-skip-ink: none; }
u:last-of-type{ text-decoration-skip-ink: auto; }
<u>parapsychologists</u>
<br>
<u>parapsychologists</u>
Note that there’s even more cutting-edge text-decoration stuff, like text-underline-offset or text-decoration-thickness.
I've been playing around with LESS for a little bit to see about converting the website I manage at work over.
When I was learning about the behavior: url(...blah) ability of css I thought I had read that it was best to use that as little as possible for performance reasons (I now can't find that anywhere so not sure if that's still valid).
So with that assumption in mind I am a little apprehensive about converting that CSS into a LESS Mixin. Is this truly a performance hit or can I safely do this without being concerned about a slow down of the site's UI?
an example of what I'd be converting...
.FullRoundedBorder
{
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
-khtml-border-radius: 8px;
border-radius: 8px;
behavior: url(/Content/CSS/PIE/PIE.htc);
}
For those that haven't seen it PIE is an awesome plugin for rounded border cross browser functionality (mainly it fixes IE 6-8).
The use of the 'behavior' property itself is not a major performance concern -- you may have been thinking of 'expression' which is indeed very bad for performance.
However, you do need to examine the performance of the specific .htc that you pull in. Essentially .htc files are pieces of JavaScript that are executed when the CSS selector matches an element. This means that the more elements that are matched by your selector, the more times that script will run.
In the case of a complex script like PIE.htc, it is very easy to use it on too many elements resulting in a noticeable delay while it runs. Like any other script, you need to be deliberate about how widely you apply it, and of course test the performance of your site after applying it.
My experience with PIE.htc is that using it on about 15 elements or fewer is not noticeable, but beyond that you start noticing a delay. There are often things you can do to lessen the impact, such as using -pie-lazy-init.
Yes, PIE will slow down the UI in IE6-8. The more effects you stack on, the greater the impact. It should not affect other browsers.
I used PIE in a (big!) project last year to get some effects in IE6-8, but upon revisiting that project this year I decided to scrap all use of PIE. I found it to be flaky and inconsistent -- it would randomly fail to render a "Pay Now" button for instance. IE users would therefore be randomly incapable of paying their bill. I switched back to Modernizr with an image fallback for < IE 9. The moral of the story is: PIE seems great, but use it sparingly and only for non critical elements. It's difficult to debug when it goes wrong.
You can also easily try it and just disable it if you find your UI is too slow with it. If your mixins are good, it should only be a few lines of code.
I've worked extensively with Less. I like how it breaks large CSS into more logical and readable chunks. A few things to consider:
1) Will you be processing the Less server side or client side? I'm more of a proponent of putting fewer load on the UI/Browser because you simply don't have control over what kind of machine, browser the user is running and it adds more points of failure in your UI implementation. Simpler is always better. If your UI is for a small audience then you should see no performance hit. In most cases I will use Less when the plain CSS would be too large to easily maintain and read and thus accept a slight performance hit, especially if the user base is trivial. For high traffic sites, I would probably rewrite or convert back to CSS and publish the straight CSS.
2) Is Less really necessary? Are you loading a bunch of translation code or running an extra process on your server just so you don't have to write a few extra lines of CSS??? This is not justification enough in my Opinion. I often question the use of other "make your life easy" libraries/tools like JQuery, when i see a developer loading an entire library just because they didn't want to write "getElementByID()" pure native JavaScript.
Everything has it's place and it's use in a project/implementation. I suggest making a list of the benefits and then eliminating those that can be readily implemented with native browser features(plain CSS and JS). Smaller and lighter is always better and faster, especially if you're also running on mobile and legacy platforms.
I hope this helped.
I recently looked at the following question:
How to disable text selection highlighting using CSS?
Which nicely provided the answer to the immediate CSS problem I was facing. However, it made me wonder, how do you determine when it is safe to drop all the browser specific prefixes for CSS properties?
I know how the mechanics of this work, older browsers which require a prefix will of course always need a prefix, so I suppose the answer really depends on the browser usage statistics.
Is there a decent, simple, source of reference that can be used to determine whether all these prefixes are really required for a CSS property, e.g. if I use the user-select property without prefixes, I can guarantee 95% of browsers will interprit this correctly.
This is an excellent summary of browser support for pretty much every CSS property.
However, I tend to use the browser-specific prefixes, as well as the non-specific rule, no matter what - it's not exactly much extra work and it will mean those few people stuck on outdated browsers still see the page as you intended.
One good resource I've used for this sort of thing is http://caniuse.com/. In general, it is not a bad idea to have a list like, for example,
-webkit-border-radius: 3px;
-moz-border-radius: 3px;
border-radius: 3px;
For the space of a few lines, this ensures that older browsers will get the right browser-specific rules if they require them, and that newer browsers get the standards-compliant rule.
Edit: Well, I noticed that the resource to which I linked does not have an entry on user-select. Oops!
I've found this to be the best resource for that:
http://www.w3schools.com/cssref/css3_browsersupport.asp
Simple question, and probably reflects my inexperience with CSS, but...
When creating a style sheet I like to explicitly specify the '*' wild card, so:
*.TitleText {
instead of just
.TitleText {
I find it reminds me that TitleText is applied to "any" tag, and can be overridden by a subsequent h1.TitleText. Maybe I just like this because for the longest time I didn't get that whole CSS selector concept properly and when I realized that the second (above) was just shorthand for the first, a lot of things "clicked".
Is what I do bad practice, good practice, or neither here nor there?
I don't know whether it's good or bad, but I've been doing CSS work as part of web app development for several years and I've never seen anyone use the * character.
While both are equivalent in terms of the style outcome, there are a couple other factors to keep in mind.
Using * increases the file size
If you do not use a CSS minifier (gets rid of unneeded data such as extra whitespace) that removes unneeded asterisks, using * every time a tag is not specified leads to quite a bit of extra characters in the file which will cause longer loading times (and more bandwidth usage). While I wouldn't go through a large file and remove asterisks already in place (unless you really have time to do so and love tedious tasks that could cause a bug you won't discover for years), I would suggest not including unneeded asterisks when writing new styles and removing unneeded asterisks when editing old styles.
Using * can lead to confusion
Using * when it's unneeded can lead to confusion, especially when someone new is working on the project and has not dealt with * being present when it's not needed (which is quite common).
Example
/**
* This matches an element with the class `alert` within
* any element within an `article` element
*/
article * .alert { /* ... */ }
vs
/**
* This matches an element with the class `alert` within
* an `article` element
*/
article *.alert { /* ... */ }
If there is 100% consistency in a project (and the style is known by all individuals working on the project), then the first example would never happen (it would be article * *.alert instead). However, this is an ideal situation and will more than likely fall apart after a few generations of developers (people love to use their own style instead). So, even if you have a consistent style, a new hire may come in and write in their own style for a short time, or read the current style incorrectly and produce code that doesn't match the selectors (or vice-versa). Therefore, I'd suggest sticking to the standard that I have seen the most (read: exclusively) in projects and websites:
Do not use the asterisk if it's not required.
A quick look at the source of some well known websites (e.g., Facebook, Google, Yahoo, etc) will show that they don't use asterisks unless they have to (even in their non-minified styles). You can also take a look at some open source projects on GitHub.
Conclusion
The asterisk should only be used if it is absolutely required (e.g., body * p to match paragraphs that have a parent other than body). Not only is this the unwritten standard (and less likely to cause confusion), but it also decreases the file size of style sheets, which increases the loading speed of the website.
Personally, I tend to only use the * when applying a rule to all tags. It is redundant in the case of *.class{}, but useful in the case of .class *{}.
I have read in a few places, but not verified, that the * selector can impact performance. It's not something I use unless I need to, as I generally prefer to be a bit more explicit, but that's just a personal preference.
It's neither good or bad, but it is (entirely) redundant.
EDIT: Actually, methinks it bad, 'cos it's potentially confusing (as in to humans, not parsers).
According to the CSS specification:
5.3 Universal selector
The universal selector, written "*",
matches the name of any element type.
It matches any single element in the
document tree.
If the universal selector is not the
only component of a simple selector,
the "*" may be omitted. For example:
*[lang=fr] and [lang=fr] are equivalent.
*.warning and .warning are equivalent.
*#myid and #myid are equivalent.
Therefore, .TitleText and *.TitleText are equivalent. It is highly unlikely that any implementation would have a performance consideration for *.xxx which is not there for .xxx.
This then boils down to a question of style. And since the considerations of style raised by the other answers seem to be to be largely moot, I believe I will go ahead and continue explicitly specifying the *.
I don't think it matters, but none of the examples I ever saw when I was learning used that wild card format, so I learned to do without the asterisk.
Also, none of the tools that generate CSS do it that way, so by using the asterisk, you risk an automated tool wiping out your format if you ever choose to put your CSS into such a tool.
Just for consistency with most other web developers, I'd probably recommend doing away with the asterisk so you don't have to deal with another developer asking why you've put an asterisk there.
I think the * is implicit, so they do the same thing.
I am not sure, but it might cause some problems if you do it like this:
span.style { color: red; }
*.style { color: blue; }
The * style will probably override the span style. I could be wrong though since span.style is a more specific selector.
I think it is pretty funny you do that, even though I totally get why! You're using DOS prompt/shell syntax with your CSS. In the end you might have been confusing yourself further thinking about it that way, since in a Shell you're looking at the file extension but in CSS it is actually mapping to a class.
So what I mean is, it works for class selectors, but kind of falls over for ID selectors. For example:
span#id { ... }
*#id { ... }
...and it no longer looks like Shell syntax. :) Personally I wouldn't do it the way you're doing it, because it might be confusing, but I don't think you're breaking anything.
That would be redundant, assuming * means 'every possible thing in the world' not having a * would also mean the same. I normally use *{margin:0; padding:0} in undo.css to reset the margins and paddings , but never as a pseudo selector.
I have never seen anyone use the wildcard like that, and I suspect it will be picked up in preference to just specifying the class. Other people modifying the styles maybe forced to keep using that syntax. That is if they figure why their classes are not working.
*.class will overwrite span.class even if span.class is more important.
I see no practical use for *.class, overwrites should be done with !important statement and only sparsely.
The only reason i use * is to remove all padding and margins, i actually always do this its the first css statement i write down always :).
There are also quite a few css hacks based on "* html" not working in IE6 and lower.
I'd flag it as bad practice.
In terms of the CSS specs, your two examples have identical meaning. However, there are potential issues with it in practice. The biggest, that I can see, is that some browsers may mistreat * in terms of rule weighting and so potentially throw off precedence (though I do not know of any, off the top of my head, that do this — it just wouldn't surprise me). It is also widely held, though I can't quote chapter-and-verse at you, that class selectors should always include a specific tag name for performance reasons. It is apparently faster to apply a class selector with a tag name (span.foo) than without and faster to apply an ID selector without a tag name (#bar) than with.
EDIT: This is pointing out that there could well be a performance issue. Some people seemed to think I was some sort on way out there rant...
While I don't know for certain, I'd like to give a word of warning! Consider the following identifier:
div#foo a.bar {}
I hear that jQuery for example, which utilizes css, would in the above example traverse the DOM looking for divs first, then check to see if they have an id of #foo, then for an A tag before finally seeing if it's classed .bar.
My concern with the * is that the browser may traverse the DOM looking for ALL tags and then look for .bar, rather than inherently just looking for the attribute of 'bar' - that's two sweeps of the DOM rather than just the one. Might be an extremely minimal difference, but if your syntax hits the airwaves, that's a few more solar panels we need to install.