css_media_queries

!meta title="Css media queries" !meta author="Kyllikki" !meta date="2015-04-03T13:09:32Z"

!toc

irc discussion

jmb if this is in libcss, then you probably only need to alter parseMediaList (and friends)

kyllikki oh thats a thought, this should probably be an interface in libcss rather than open coded in the browser

jmb seems reasonable, given libcss needs it too

kyllikki I worked my way to where it was currently done and it extracts the entry from the link and does string messing on it

jmb yeah; that's hideous, and should die

kyllikki ok so how ought we to do it?

jmb first, we need to change how libcss represents media. currently, it's a bitfield. which clearly doesn't work for media queries. so, that needs to be an object, instead. which probably isn't much work to change. then, in libcss' parser, parseMediaList will need to change to understand the new media query grammar

kyllikki ok, i think i know what you mean. thats just altering the internal libcss representation?

jmb mostly. And then, finally, we need to expose an api to allow a client to parse an arbitrary string as if it were a media query list. that should return the new media object. that's needed, because of

 `

kyllikki right, which is all we currently support right?

jmb libcss supports @media rules.

<style markdown="1"> may also have a media attribute. though I don't recall if NetSurf supports that. **kyllikki** it does indeed carry it and netsurf does not support it **kyllikki** so how does libcss make decisions about applying the rules? it obviously has no knowledge of any of the state **jmb** see the selection api. when you add a stylesheet to a selection context, the client provides the media it applies to (e.g. css\_select\_ctx\_append\_sheet) **kyllikki** so we have netsurf call the new libcss api to get the media object and pass that instead? **jmb** seems reasonable **kyllikki** but how does libcss make an actual decision whether to apply the styling or not? **jmb** there needs to be a way to construct one computationally, too (rather than from string), as the client must also pass a media descriptor into css\_select\_style. which I think answers your question :) **kyllikki** not sure how they are comparable though. I guess thats implementation detail **jmb** likely. today's implementation uses & .the basic concept is: style information has associated metadata that says what kinds of media it applies to **kyllikki** I guess we have to figure that providing a media object that represents the browsers current media state is enough to make media selection comparisons *'jmb* and then, when selecting a style, you know what media you are selecting for, and can then include/exclude specific style information based on that. and the metadata either applies to the whole of a stylesheet (be that or <style markdown="1"> ), or it applies to part of a stylesheet (through the use of @media within the CSS). libcss already has all the plumbing for that logic; it just doesn't have a rich enough mechanism for expressing media information. or the parse implementation for media queries ;) **kyllikki** so - first up is moving the existing media api to be an object - then ensuring the browser creates such objects where needed and passes them - only then should the parse api in libcss be expanded, given it already has one for @media and we want it to be universal **jmb** ya **kyllikki** so we are already just fucking doing it wrong **jmb** well, media queries weren't mature enough when libcss was first designed for them to be considered and all the stuff in NS mostly predates libcss, anyway -- certainly that media attribute parsing on link elements has been around forever **kyllikki** yeah but we always add sheets fetched from the dom as screen! **jmb** "oops" :)