diff options
author | Daniel Silverstone <dsilvers@digital-scurf.org> | 2017-02-04 09:41:13 +0000 |
---|---|---|
committer | Daniel Silverstone <dsilvers@digital-scurf.org> | 2017-02-04 09:41:13 +0000 |
commit | e7366bf41f68cfe07e9ea03fc4a398baecbae651 (patch) | |
tree | 5bb9c3cbe7eab7e70ff1ebd65d9de59a694762df /css_media_queries.mdwn | |
download | netsurf-wiki-e7366bf41f68cfe07e9ea03fc4a398baecbae651.tar.gz netsurf-wiki-e7366bf41f68cfe07e9ea03fc4a398baecbae651.tar.bz2 |
Initial conversion from MediaWiki, 20170204
Diffstat (limited to 'css_media_queries.mdwn')
-rw-r--r-- | css_media_queries.mdwn | 116 |
1 files changed, 116 insertions, 0 deletions
diff --git a/css_media_queries.mdwn b/css_media_queries.mdwn new file mode 100644 index 0000000..cbd91f7 --- /dev/null +++ b/css_media_queries.mdwn @@ -0,0 +1,116 @@ +[[!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 + +` `<link type="stylesheet" media="<query>`">` + +**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** +<https://html.spec.whatwg.org/multipage/semantics.html#the-style-element> +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 <link> 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" :) + |