-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-text-decor] No way to set the underline width/thickness #239
Comments
The thickness of text decoration lines are controlled by fonts in general. |
I know, so what? What if you want a thicker line without increasing the font size, or viceversa? Also, different browsers render lines of different thickness even with the same font size (and yes, they are actually using the same font), because no standard tells them how thick the line must be; so, you may want to set an explicit value for consistency across browsers. |
The color of the decoration line by default is controlled by the text color. Does that mean the property |
There are use cases for different color for decoration lines. Thickness is, hmmmm, I have no idea. As far as I can see, normal word processors includeing Microsoft Word and Apple Pages do not provide option for thickness of decoration lines, either, which may indicate that this isn't something with high demand. Microsoft and Apple must be kidding you as well :) For implementation, it doesn't seem to be something very hard to add if the spec is clear, so I'm not strongly against this, anyway. |
If this is w3c's way of reasoning, well, that explains a few things.
What about this use case: "i want a thicker line". How is that less obvious than "i want a line of a different color" or "i want a dashed line"?
Now you really must be kidding me. Is that what inspires css specifications? But that again would explain a few things. (btw i don't use word processors but yes, Microsoft and Apple do do idiotic things and their products often do have ridiculous bugs or lack obvious functionalities, so i don't see why that should be a surprise)
That's kind of an understatement. It seems totally trivial, especially if compared to other stuff that already is in the specs.
How someone could be even mildly against something like this is beyond me. |
And if you still doubt there's demand for this feature (btw, a spec body should anticipate demand for features, not be driven by it, let alone even question how high it is) just Google for "underline thickness css" and the like and look at the number of questions in Stack Overflow (the usual answer being "use border-bottom", because as Einstein said...) |
Note that this topic already came up several times on the mailing list. E.g. @LeaVerou started a thread about this in 2014 and Lutz Issler in 2012. Sebastian |
@teo1978 Your aggressive tone is unlikely to get you any friend. You have a valid point to discuss, no need to be angry about it. Attacking the first person who finds your point interesting enough to consider, even if they don't agree with you won't get you very far.
The w3c isn't one person, and it doesn't have one way of reasoning. Different people have different reasons for supporting or opposing things, and you need to convince enough people that your suggestion is useful to make something happen. You seem to have fairly good arguments. I would be a pity if people dismissed you as a troll and stopped listening (Just to be clear, this is not a threat). MS Word and Apple Page are not taken as models to follow or as a source of inspiration. But they are an OK way to evaluate if something is commonly used / needed. Your answer that people ask for it all over stack overflow is a good counterpoint, but Microsoft or Apple bashing will get you nowhere. |
Simple things that look sort of useful, but are requested by few people still take time to argue about (syntax, specific semantics, corner cases...), document, write test cases for, implement in multiple browsers, verify that everybody does it the same way. Doesn't mean it can't be done, but even simple things have a cost when you want to make them into a standard, and all implementors already have a gigantic backlog of things they think are important and want to do. So if you want this, it's on you to convince them they should devote time away from whatever it is they are currently doing to take care of this. Proof that lots of people want it help. Proof that it cannot (easily) be done by some other way help. Proposing a syntax helps. |
https://lists.w3.org/Archives/Public/www-style/2011Mar/0593.html |
#459 is basically a duplicate or continuation of this issue. |
(Migrated from #459) Being able to control thickness of underline is something that we have often seen web authors request. Designers often want to control the thickness and position of underlines. Typographically, these underlines often are the thickness of certain particular strokes inside glyphs, which browsers / text libraries have no concept of. Therefore, information required for higher quality sizing / placement must come from somewhere else. Naively, this additional information could come from the "post" table inside font files. However, because this information is often unused, many font files have garbage data in these fields. (As an aside, I committed a patch to WebKit to use these fields, but had to revert it 7 hours later because of the low-quality data.) Therefore, this information should come from page authors. There should be a new property: The For the "number" value, a value of '1' represents 1px at font-size: 16px, and scales linearly with font-size. There was some discussion in #459 about creating CSS units which refer to the stroke width(s) of a font. However, that idea is separate from this one because, even with CSS units, this property is still required so that the units can be specified. In the proposal above, there is no value accepted, but if new units are created, this property can be extended to accept a new value. For now, though, this proposal doesn't include that piece. |
This seems confusing … Why not just allow the same kinds of length values that are allowed for most other size properties? That way if someone wants the line weight to correspond to the font-size, they can specify it as an em-based value. |
@nicksherman is right. A magic numeric value is not very CSSish, just use a length and provide at least one useful new unit for it. A certain unit may default to |
A length is bad because it doesn't scale with font-size. |
@litherum The main benefit of lengths specified in |
@litherum A length specified in em, ch does scale with the font size, but authors also have the choice of units that don't scale with the font size. Flexibility is good! |
Sure. We should probably add a note mentioning that the font-specific units should be used. |
I don't see why such a note is needed at all. Specs are primarily read by implementors, not authors. Also, authors are pretty familiar with em units by now, so I think it's a but superfluous. We don't have such a note in |
Specs are (hopefully) also read by tutorial writers and other educators. |
Only the few really good ones. Most of them just read other second-hand info (other tutorials and MDN or similar). |
A little bit off-topic, but in CSS2§1.2:
As for this issue, I think the details of the spec text (e.g., whether a note is needed) can be discussed after discussing the proposed syntax (i.e., property & values). |
I prefer established @font-face {
font-family: Example; src: url(example.woff);
stroke-width: 0.05em /* base-stroke */ 0.05ex /* hair-stroke */; /* `auto` would trust metadata */
}
.example {
font: 16px Example; font-size-adjust: 0.6 /* 1ex = 9.6px */;
text-decoration-width: 1bs; /* = 0.8px or actual stroke width or default 1em/16 = 1px */
font-weight: 120%; /* = 1.2 × 1bs / (1em/16) – different definitions possible */
} |
This feature has been on the to-do list for CSS Text Decoration Level 4 since its inception, fwiw. Just been waiting on Level 3 to stabilize more and garner further implementation before continuing work on L4. Since I've just completed the DoC for L3's second CR stage, I took the liberty of drafting up a proposal in the L4 unofficial draft, which you can find here: https://drafts.csswg.org/css-text-decor-4/#text-decoration-width-property Comments welcome. I anticipate that the WG will approve the addition in principle since, as mentioned, this has been requested multiple times and it is a relatively straightforward feature. That said, I'd like to have the revision of L3 prepared, approved, and published so we can fold it into the L4 draft before publishing FPWD, so there does remain a bit of work on L3 before this gets 100% on track. L4 is currently a bit sketchy with most of its text missing. ^_^ +1 to everything Florian said, btw. It's not that we don't care, it's that there's a million things to do and limited time and resources with which to do them... |
@fantasai Thanks for the I'm not sure that We do, however, probably want some prose describing whether underlines grow down or up. It seems to me that underlines should always grow away from the baseline. |
It's probably too early to bike shed, but "width" usually means "horizontal width" which is inaccurate in this case. "Thickness" seems more accurate. |
True, but I'd value internal consistency (consistency with the rest of CSS) more than external consistency. We tend to use |
The term "stroke-width" is pretty universal in graphic arts. and two of the four borders are vertical; no-one seems to find border-width confusing. |
Are we never going to add a property to control the width (the horizontal length) of underlines? If there were any possibilities, we may regret to have used the term for the thickness. |
@svgeesus agree, |
@kojiishi I would personally call that |
The em note is a good tip for getting widths relative to font-size, but I wouldn't want "strongly encouraged". 'ch' and 'ex' would also be good choices there. Some authors want type-relative thicknesses, others (like me) think that looks weird, and would never want more than 2px or less than 1px. I also wouldn't want fractions of a device pixel (which might be rendered as less than full opacity). |
The L4 text should maybe say that the 'auto' value is generally expected to be the same thickness as an underscore character, or something, and might also be derived from PostScript/OpenType tables. UAs can also set lengths in their UA style sheet, if they want something different from that, such as 1px or calc(1em / 16). |
s/set lengths/set widths |
The CSSWG resolved to add If there are problems with specific details of how it's specced, please file new issues. Thanks! |
https://drafts.csswg.org/css-text-decor-3/
There's no way to set the thickness of the line underlining text in a
text-decoration: underline
?? You must be kidding me.The text was updated successfully, but these errors were encountered: