Re: CSS support in libsvgtiny

Hi Michael,

On Tue, 12 Sept 2023 at 23:45, Michael Orlitzky <michael@orlitzky.com> wrote:

> tl;dr has anyone tried to use libcss to add CSS support to libsvgtiny?

Not to my knowledge. It's definitely something that's worth doing.

> 1. First, I chose to implement the fill-opacity and stroke-opacity
> properties because they're easy. They have the same form as the
> usual CSS "opacity" property. To implement them, I basically
> git grep'd for "opacity" in libcss and copy/pasted everything to
> fill-opacity and stroke-opacity. It was tedious, but otherwise
> not difficult because opacity is easy to parse.
>
> Handling the more complicated properties or factoring out the
> shared implementations of opacity, fill-opacity, and stroke-opacity
> would likely require someone who knows libcss better.

That's fine.

> I dumped the new properties into the default level, but this raises
> a question: should libcss use a different CSS level for SVG?

Good question. What do you think John-Mark?

> 2. In libsvgtiny, I added a libcss context to the parser state, and
> then taught the SVG parser to parse a <style> element into a sheet,
> and append the sheet to said context. This part is just boilerplate.
> The build system needs to be updated to build/link against libcss.
>
> 3. I copied the css_select_handler and css_unit_ctx from netsurf into
> svgtiny.c. Thankfully, I didn't have to think about the unit
> conversions at all because opacity is a float. The select handler
> callbacks were tedious, but most of them can be copied from netsurf
> with minimal changes, fudging interned string names and replacing
> html-only function calls. I wound up copying the user data handler
> too. Who knows if any of this stuff works, but it hasn't crashed.
>
> Ultimately, since netsurf uses libsvgtiny, copy-pasting the select
> handler wouldn't be a great solution. I think it would make sense
> to factor out the libdom/libcss integration into something like a
> libdom-css that provides a generic css_select_handler
> implementation.

I agree, it would be better to have a shared implementation of the
LibCSS/LibDOM integration. Either as a LibDOM-CSS or maybe as
an optional LibDOM binding for LibCSS, a bit like LibDOM has
the Hubbub/LibXML bindings. What do you think John-Mark?

> 4. I added fill_opacity and stroke_opacity members to the SVG parser
> context.
>
> 5. I taught svgtiny_parse_paint_attributes() how to find the computed
> fill- and stroke-opacities. We're already parsing the inline style
> so that part is pretty easy. Once we have them, they can be set in
> the context. Disclaimer: I skipped composition with the parent
> style to save time, but that could probably be copied from netsurf
> too.

Composition is mostly to handle inherit. If those properties aren't
inherited, it won't make a difference at the moment.

> There's a problem here: the SVG parser makes one pass through the
> file, using a big struct to keep track of the current color, stroke
> width, et cetera, as we create and append shapes to the resulting
> abstract representation. If a <style> element appears at the end of
> the SVG, its rules won't affect the shapes created earlier. (This
> isn't a huge problem, it's just worth noting that I half-assed this
> part to get the thing working.)
>
> 6. You can now render each shape with the fill_opacity and
> stroke_opacity from the context.

Cool!

> Now I can say I wasn't lying when I thought "I could probably do
> that." Of course I skipped over the boring/hard parts, but when all is
> said and done, the framework can be put in place without too much
> extra code.
>
> Does it make sense for libsvgtiny?

Yeah, certainly!

Best regards,
Michael
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org