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.
Related
I am new to HTML5 and CSS3. I was just seeing some CSS3 code which is as below:
.box
{
border-top-left-radius:5px;
-webkit-border-bottom-left-radius:5px;
-moz-border-top-left-radius:5px;
border:1px solid #8e8e8e;
background-color:white;
height:16px;
padding:4px;
padding-left:28px;
padding-right:10px;
color:#4a4a4a;
float:left;
}
I couldn't get why after border-top-left-radius border radius is mentioned with -moz and -webkit prefixes? Is syntax for different browsers different? Is it now being standardized?
Yes, the syntax can be different with experimental properties. This is entirely up to a vendor to decide, because a vendor-prefixed property is considered proprietary and not part of the standard.
In particular, Mozilla called it -moz-border-radius-topleft, not -moz-border-top-left-radius. The code you're looking at is mistaken (possibly a result of blind copying and pasting of declarations).
It has since been standardized to border-top-left-radius. The prefixed properties are only there to support older versions of browsers. For that matter, the unprefixed property should come last in order to ensure a browser's best/most stable implementation of a property.
To clarify what BoltClock said: The browser creators Microsoft, Google, Mozilla and such decide which parts of HTML and css to implement in their browsers. Most of the companies want people to use their brand of browser, because this means they can give a better experiance or direct you to their own propriety sites, Thus extra features such as new CSS-tags or other useful developer tools has been developed trying to get an edge on other browser-vendors.
This has been going on for a long time ever since the first browser was launched in the 1990:s. Netscape provided their own features and Microsoft came late into the game and had a hard time getting up to speed. In those times it was not certain that browsers would be free and so much effort went into making the best browser, and different features arose. Later when W3C came into the picture and started the work of standardizing the web vendors slowly but surely started to adhere to standards. That work is still in process and will most likely need to continue for quite some time.
There is a brilliant course on coursera that touches this subject. Check it out!
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
From a blog:
The basic idea with CSS expressions is
that you will have calculation and
dynamic values for properties in the
CSS code, something that people have
found very useful. A simple example
can be implementing max-width behavior
in IE 6:
width: expression(document.body.clientWidth > 1100)? "1100px" : "auto";
This is the first time I read about them. It seems IE used to support CSS expressions but dropped them in IE8. What other browsers still use them and are they generally a good or bad thing?
The blog post I got this from says the alternative is Javascript, but I thought CSS was more supported and therefore better than Javascript.
AFAIK, it was only ever IE6/7 (maybe) 5.
I never thought they were a good thing. May as well just use JavaScript directly.
They are in fact implemented in JavaScript, and I'm pretty sure disabling JS disables these expressions.
The sample you posted...
width: expression(document.body.clientWidth > 1100)? "1100px" : "auto";
...is just a ternary operator that says If the width is larger than 1100px, set it 1100px, otherwise set property to auto.
To finish, no scripting language on the web is more widely supported than JavaScript.
Expressions are unique to IE and were dropped in 8:
http://msdn.microsoft.com/en-us/library/cc304082(VS.85).aspx#expressions
More about expressions:
http://msdn.microsoft.com/en-us/library/ms537634(v=VS.85).aspx
Firefox has a similar setup, XBL - check out this answer to a very similar question. HTML5 editor Ian Hickson recently stirred things up a little by releasing a new draft of the W3C attempt to standardize XBL (see also the WG response), so we may ultimately see something similar to Microsoft 's expressions as part of the HTML5 family of technologies.
I am trying to figure out the most efficient way to ensure cross-browser compatibility. I have done a bit of research and learned a few interesting things such as the fact that Mozilla/Firefox can't handle a class that has a name starting with a number. Is there a way to make a CSS work for any browser or is it better to just develop multiple CSS and add code to choose which to use based on the browser being used?
You might consider using a CSS Framework such as Blueprint. It includes a CSS reset that should help.
Also, you might want to look at Yahoo's CSS reset
An aside to clarify a point:
... I have done a bit of research and learned a few interesting things such as the fact that Mozilla/Firefox can't handle a class that has a name starting with a number....
Sorry, but that's not a Mozilla limitation, it's in the CSS spec: class names must not start with a number. Any browser that allows them to isn't enforcing the rules properly.
Answered here on StackOverFlow. The relevant part of the spec is at http://www.w3.org/TR/CSS21/syndata.html#characters (see the 2nd paragraph).
To answer your question: There is no way to make a page using just one universal css and have it displayed equally in all browsers, unless you only use an extremely small sub-set of all available css (selectors, values, etc.).
The way I work is:
Use a css reset
Develop for a browser that adheres to the standards pretty well (Firefox, Chrome, Safari, Opera)
Patch things up for IE using conditional comments (because you'll probably need things that don't validate)
A good starting point would be to use CSS reset such as: http://developer.yahoo.com/yui/reset/
Your goal should be CSS that works on all browsers. If you start out with a CSS file per browser, where do you stop? Mobile Safari? Flock? Konqueror? Every version of every supported browser?
Eventually, you might need to compromise, but you can cross that road when you get there.
Regardless of your infrastructure/framework/etc you should test your code on all major browsers. If possible avoid using style sheets for browser specific problems. Browsers will change and adapt which means you might get stuck having to update a bunch of websites when new browsers come out.
CSS is a fickle beast and I haven't found any solution that covers all the quirks except for a lot of due-diligence and testing.
You might use a framework that does this for you, such as GWT, but keep in mind that you will still have some issues.
Like every web developer, I usually curse the creators of IE6 with foul and untimely deaths at least once a week. Yet my company requires me to keep supporting that most-hated of browsers.
My problem today has been wanting to first use a wildcard in my CSS and then trying to use the "inherit" property instead. Neither of which are supported by IE7-.
I really, REALLY want to have good, well-structured, properly-inheriting CSS (object-oriented CSS, if you like that buzzword) but I have that sinking feeling in the pit of my stomach that sooner or later, it's going to have to be custom-purpose and location-based classes.
This poses the question: given how utterly awful IE is at handling many CSS concepts, is it impossible to adequately support this browser at the same time as having a well-structured CSS document?
Just to clarify: I'm aware that there are plenty of ways (some legitimate, some less so) to get around the bugs and shortcomings found in IE6 and 7. What I'm really asking is "if you want to have a single, well-written stylesheet that inherits correctly, must you choose between that and having a consistent look across all browsers?". Hope that makes sense.
In other words, should I stick to my principles and code a good style sheet or should I accept that IE6 still enjoys a horribly high (20% on last count) market share and bring myself to support it? Or is there some happy medium that allows me to minimise the frankenstein surgery on my HTML and CSS while still achieving some respectable results in IE?
To be fair, you can't blame it all on IE (though Microsoft certainly is by far the worst transgressor). Part of the problem with such large & rapidly-evolving standards is that it's too much of a moving target to be perfectly implemented in a timely fashion. Unfortunately, the release cycles of web browsers do not coincide with the release of new web specifications. So all browser developers can do is try to implement as many features as they can from the latest W3C recommendations, selecting what they think will be the most commonly used features to implement first.
However, things are clearly improving, and it is possible to support IE6/7 and still use proper CSS design. It's just... difficult. Take a look at this comparison of layout engines & CSS support. If you look at the overall trend, you'll see that most browsers (even IE) do tend to comply with established standards in the long-run, it just takes some browsers longer than others to implement a standard after its introduction.
And sometimes it's not that one browser is "less" standards-compliant than another. With new standards the problem is often that different development teams chose to adopt different parts of the new specification. So even though CSS3 is already beginning to be implemented by most browsers, we'll probably have to wait until CSS4 is published before seeing consistent support across all major rendering engines. And if you try to use the latest CSS3 features right now, you'll have a hard time establishing compatibility across all major browsers. But if you're using features introduced in CSS1, it's no problem at all.
Therefore, the only option--aside from using ugly CSS hacks--is to stick with well-established older specifications. Then the problem is no longer trying to conform to web standards while supporting a particular browser. Instead the problem simply becomes trying to resist the urge to use the latest & greatest CSS features.
Aside from that, the only permanent solution I see to this recurring situation is for the W3C to prioritize different parts of newly introduced specifications so that the new features can be implemented in discrete phases synchronized across all the major browsers. So, for instance, grammar rules might be given the highest priority along with a set deadline for its implementation. After that would come the second phase, which could be element & attribute selectors, and so on and so forth.
This would require a tremendous level of cooperation between the W3C and development teams, but it would be worth it. After all, it does users and web developers no good for IE to implement one subset of features from CSS3 while Firefox implements a different subset and the Webkit browsers yet another subset. A "standard" is no good until it's actually standardized across all the major rendering platforms. It's better for each browser to support fewer new features but have them all be the same features, than for them to separately introduce a ton of their own features that aren't universally supported.
Not at all - you can compensate for IE's shortcomings with conditional comments and an IE specific stylesheet, while serving your 'nice' stylesheet to other browsers.
Something else which I find helps is to use a CSS reset. While this isn't going to resolve all of IE's issues, it does give you a good baseline to work from.
The most anoying IE6 feature is it's box model handling. You should stick to margin instead when positioning boxes, and try to use relative font sizes to allow font resizing on IE. The rest of the quirks are well documented.
Using conditional comments is the cleanest way of having both a clean style sheet for well behaving browsers, and still using being beautiful on IE. This is what I use, only needing 1 css file of a few lines to repair my sites look and feel.
The dark path of crossbrowser consistent look & feel are css hacks, but I strongly discourage it's use, specialy now that for some time we'll have to target three different IE (6, 7 & 8)
Normally, if you get the style to work in both FF and Chrome/Safari, IE is only a few corrections away of being correct.
There is a great site Position Is Everything that details how FF, IE and Safari conform to standard CSS. At the site you will find most of the workarounds / cures for IE that will alleviate the need for you to write so much conditional code for your CSS.
You'll also want to check out A List Apart for more on CSS and IE. There are also great articles on tableless layout with CSS, handling the height bug in IE, etc. Good luck - IE 6 really sucks when it comes CSS.
Certainly not. If you ensure that they render the page in "standards" mode as opposed to "quirks" mode many of the common IE CSS issues are resolved. To do this you must provide a valid doctype statement at the top of the page, such as
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
As others have pointed out, another good idea is to start off your stylesheet with a snippet that removes all paddings and margins like so:
*,html {
margin: 0;
padding: 0;
}
Finally, one common problem with CSS based layouts in IE is that clearing of floats doesn't happen when you'd expect. This is to do with a hidden object property in IE called "hasLayout"; only objects that "have layout" will correctly wrap around and enclose floated child objects. It is easy to ensure that your containers "have layout" simply by specifying at least one dimension for them:
height: 1%;
width: 100%;
zoom: 1;
I do not personally use conditional IE stylesheets except for one single thing: to replace PNG backgrounds with GIFs in IE < 7 - there is nothing wrong with using them, I just find it unnescessarily complicates things when you have to define the appearance of the same object in two different places. With the three tips above and a bit of patience you should be able to create CSS based layouts using a single stylesheet that render just as well in IE 6/7 as they do in Mozilla/Webkit.
Happy coding!
IE 6 really does limit what we can do.
It’s the lack of support for advanced selectors (and inherit — IE 7 doesn’t support that either) that gets me. Just having the child selector and attribute selectors would be nice, that’d really cut down the amount of code we have to write and maintain. You can only work around the lack of support for them by duplicating your styles, so you just end up having to code as if they didn’t exist.
Sigh.
Only follow online CSS tutorials that is rendered correctly with IE6 and Chrome (or Webkit). If it looks right in both, it likely looks right in (almost) all browsers.