Re: [strokes] CSS fill/stroke spec + questions

Brad Kemper
> On Jan 25, 2016, at 3:32 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> Per an FXTF meeting some time ago
> <https://lists.w3.org/Archives/Public/www-style/2013Jun/0678.html>,
> fantasai and I have been drafting fill/stroke as applied to text in
> CSS, and with the extensions needed to handle multiline text,
> hierarchical elements, and multi-layer (background-like) paints.

Thanks for the work you put into this. My initial reaction is that it isn't ambitious enough. See below. 

> Currently this lives in the Text Decoration 4 ED
> <https://drafts.csswg.org/css-text-decor-4/>.  Is this appropriate, or
> should it live somewhere else less directly text-centric?

I'd like to see the dashed strokes capabilities applicable to regular borders. I've had this in my head a long time, and I think a 'dash()' function as a value of 'border-style' would be better all around than having a 'stroke-dasharray' property (btw, this hyphenation is too weird, and I don't care how they have it in SVG). Then 'dashed' and 'dotted' could just be shorthands. For instance: 'border-style: dash(0 1 round)' would mean "a zero-length dash with round endcaps, and one border-width length of space between endcaps", which could be a nice definition for what 'border-style: dotted' is. 

I feel this is more important than having the same thing for text, but I'd use the same values for a new 'text-border-style' property, and also have the other main border properties (not including border-image) replicated with a 'text-' prefix. That would make it simpler to use and easier to learn and understand. 

> We're also unsure exactly how much of fill/stroke to define in this
> spec.  Should we take over the entire model, copying text from SVG, or
> should we only define the syntax, and the rendering parts that are
> relevant to CSS, letting SVG define the rendering parts important to
> it?

Please design for people familiar with CSS and HTML, then back-port to SVG. That's why I'd prefer integration into existing or new border and background properties, and prefixing those with 'text-' when something similar should apply to glyph shapes (kind of like box-shadow/text-shadow, but without needing the 'box-' prefix).

Some other thoughts on the draft:

Issue 9, percentages: I would like percentages to mean percentages of the side it is on, for rectangles, and percentage of the whole stroke for other shapes. So, 'border-style: dash(25% 50%)' would have a dash that started in the top left corner and continued for 1/4 the width, have a centered gap that was half the width, and then (because the pattern repeats), another quarter-width dash from there to the top right corner. 

This would be a nice way of having borders that were only on the corners, or centered borders that didn't go all the way to the corners. The author could set it up so that the dashes and gaps were always symmetrical, using the same general syntax as for other custom dashed lines. 

Issue 10, commas. It would be much easier to read if dash/gap pair was separated by commas (a comma after each gap, unless it was the last item of the array). Thus, 'dash(6px 6px, 4 4, 4 1fr, 4 4, 4 6px, 6px)', which makes it clear that it starts and stops on a dash,  instead of 'dash(6px 6px 4 4 4 1fr 4 4 4 6px 6px)'. 

PS. The '1fr' there is supposed to be a flexible measure, once the other dashed and dots are fit to one side of the rectangle. Maybe a level 2 feature?

Also, this comma syntax would allow you to start out with a gap, by just having a single measurement before the first comma ('border-style: dash(8px, 5px 8px);'). Then you don't need stroke-dashoffset as much. For when you do need stroke-dashoffset, I'd have it as the first measurement of the function, followed by a slash. So, 'border-style: dash(1in / 5px 8px)' would be repeating 5px dashes with 8px between them, starting 1in from the corner. 

Stroke-align: I'd have a 'border-align' property to describe where the border goes. The initial value would need to be 'outset', to describe where borders are currently drawn, at least for how it would apply to 'border'. It could be different for 'text-border', I guess. 

This also seems to be missing something that would allow the stroke/border to be outset from the shape by a specified distance. I thought SVG had that.

Received on Tuesday, 26 January 2016 03:37:35 UTC