Re: [CSS3 Text] Text decoration and Line decoration

Arron Eicholz wrote:
> I have a couple of concerns with the latest proposal and removing some of the properties from the
> last CR. Let me see if I can point them all out and come up with viable solutions.
> 
> These situations assume that you have no access to editing the markup. You only have access to
> edit the CSS.
> 
> Issues:
> 
> 1: What if an editor wants to have a 'solid' line-through but there is already a 'double'
> underline in the original text? This is a viable situation for editors that want to track changes
> but don't want to change the context of the document by altering the underline which may have
> some additional meaning.
 >
 > 2: What if the editor wanted a line-through to be red and an underline to match the text color.
 > This again could be the same situation as issue 1 because changing the underline color may change
 > the context or meaning of the text.

For editors that track changes (or mark spelling errors), they presumably also need
to handle changes that are only part of the underlined element. In this case it is
necessary to add another element (or pseudo-element). So that use case requires a
new element. And it would be silly not to add the new element just for changes that
*happen* to coincide with the boundaries of an existing element.

Purely from a markup point of view, such things should be their own elements anyway,
e.g. the <del> element in HTML. And stylistically, what if you wanted to mark
changes by drawing red boxes around them? You'd need a new element even if the
change coincided with an existing element.

> 3: text-line-skip again we need to think about situations where I want my line-through to go
> through images but my underline not to go under images. This I think could be handled by an
> additional selector for 'img' but if we change the rules based on 1 and 2 then this should follow
> the similar pattern.

That's an interesting use case. Noted.

> 4: text-line-skip should also have the ability to have multiple values. What if the developer
> wanted to skip both spaces and images but not ink?

Yes, that was my intent. I should have written
   none | [ images || spaces || ink ]
instead of
   none | [ images | spaces | ink ]

> 5: for backwards compatibility sake we should leave text-decoration alone or deprecate it all
> together in CSS3.

It's actually better for backwards compatibility this way. It handles both
these cases:

A) I want to have a red dotted underline, which falls back to a regular
    underline in old UAs.

   element {
     text-decoration: underline;
     text-decoration: red dotted underline;
   }

B) I want to have a red dotted underline, but fall back to nothing in old UAs.

   element {
     text-decoration: red dotted underline;
   }

You can even do

C) I want to have a red dotted underline, but fall back to underline +
    overline in old UAs.

   element {
     text-decoration: underline overline;
     text-decoration: red dotted underline;
   }

> 6: The text-line-color initial value is 'currentColor' I did a search through the module you
> referenced in the old CR and I can't find 'currentColor'. Did I miss it somewhere?

   http://www.w3.org/TR/css3-color/#currentcolor

> 7: text-line-skip what about skipping controls (buttons, checkboxes, radios, etc..) or replaced
> elements?

"images" skips over all replaced elements. I thought "images" would
be a more author-friendly name than "replaced", which doesn't mean
anything unless you make a habit of reading the specs.

> 8: text-line-style has a value for wave and in your example in the CR this looks more like a
> zig-zag to me as opposed to a wave which I would expect to be more curved. (I assume the
> rendering is non-normative but wanted to point it out that we are limiting our ability to expand
> by possibly using terminology that isn't quite right for the situation).

(That would be Michel Suignard's example, technically.) I have no
objection to improving our examples. The 'wave' form should indeed
be curved.

> 9: as for the text-underline-width and other respective properties; I don't think width is
> necessary at this time. I think in the future it might be useful but as of right now, and even if
> we do add this additional functionality to the spec, I don't see a pressing need to be able to
> change widths.

Ok.

> 10: text-blink this is an interesting idea however I think if we do separate out the blink value
> like this we should change the values to accept a frequency or some sort of timing.
> 
> Possible solutions:
> 
> 1, 2 and possibly 3: bring back the individual properties for underline, overline and
> line-through. With these properties we would have the most flexibility and the most extensibility
> moving forward into CSS4. I know this creates a lot of extra properties but it is very usable
> this way with very little complication of possibility for confusion with what would end up to be
> very complex properties if we try and keep things combined and try and do this in the future.

In creating properties, we need to not only consider the complexity of
implementations, but also the complexity the author needs to deal with.
For text decoration, I think the old system had way too many properties.
It also combined text-decoration's "on/off" switch with its "line style"
switch, which I think is a less useful model in practice: it makes it
more difficult to take advantage of the cascade.

Consider: I want to underline links only on :hover and :focus. I want
site-external links to have dotted lines, and links that open in a new
window to have double lines. In the proposed system, I can do

   :link, :visited
     { text-decoration: none; }
   :link:focus, :visited:focus,
   :link:hover, :visited:hover
     { text-decoration: underline; }
   .external
     { text-line-style: dotted; }
   [target]
     { text-line-style: double; }

With the CR's set of properties, I'd have to do

   :link, :visited
     { text-decoration: none; }
   :link:focus, :visited:focus,
   :link:hover, :visited:hover
     { text-underline-style: solid; }
   .external:link:focus, .external:visited:focus,
   .external:link:hover, .external:visited:hover
     { text-underline-style: dotted; }
   [target]:link:focus, [target]:visited:focus,
   [target]:link:hover, [target]:visited:hover
     { text-underline-style: double; }

If you're concerned about the ability to color underlines and overlines
independently in CSS4, I also submit that we should have multiple
underlines in CSS4. When we design a feature for multiple underlines,
that'll probably solve different-colored underlines and overlines as a
side effect. So I'm not worried about multi-colored text decoration CSS4.

> Also why is text-underline-position the only oddball property in text for line drawing? It just
> doesn't seem to fit with the current plan and is another reason to go back to individual
> properties.

The correct position for the "underline" semantic, particularly in
vertical text, is script dependent. This propertly allows that
adjustment, which is not necessary for strike-throughs and overlines.

> 4 and 7: Values: none | [ images || spaces || ink || input(<input-type>) || button || textarea ||
> object ]
> 
> <input-type> values : text || password || checkbox || radio || submit || reset || file || image
> || button
> 
> Of course this list could/should be updated for Web Controls 1.0.
> 
> There is an additional question for the setting of 'button' does that also include the input
> buttons (submit, reset, button)?

I think that's a little excessive, and tied too much to the markup.
I'd rather just add a 'form-controls' value: that should handle
most use cases, no?

> 5: My suggestion would be to deprecate it. Or if we want to leave it around then that is fine but
> it should not be altered in any way and should not be a shorthand for these new properties.

See above.

> 8: See the old Borders CSS3 module
> (http://www.w3.org/Style/Group/css3-src/css3-border/Overview.html#the-border-style) for an
> example of what wave would look like from my point of view. This would mean that the very jagged
> example you have in the CR would be more like 'zig-zag'

Yeah, the examples need work. I've been focusing on spec text so far;
it's less work to do the examples after the normative stuff is settled.

> 10: Create a new property 'text-blink-frequency' and use 'text-blink' as the shorthand property
> 
> Name: text-blink-frequency Value: faster | slower | <frequency> | <time> Initial: 0 Applies to:
> all elements Inherited: yes Percentage: N/A Media: visual Computed value: I'm not 100% sure here
> but I think it would calculate out to time in milliseconds
> 
> Name: text-blink Value: none | blink [ <'text-blink-frequency'> ]? Initial: none Applies to: all
> elements Inherited: no Percentages: N/A Media: visual Computed value: specified value (except for
> initial and inherit)

I think just
   text-blink: none | blink | <frequency>
would be sufficient.

~fantasai

Received on Thursday, 19 July 2007 18:51:44 UTC