From e7366bf41f68cfe07e9ea03fc4a398baecbae651 Mon Sep 17 00:00:00 2001
From: Daniel Silverstone <dsilvers@digital-scurf.org>
Date: Sat, 4 Feb 2017 09:41:13 +0000
Subject: Initial conversion from MediaWiki, 20170204

---
 css_media_queries.mdwn | 116 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 css_media_queries.mdwn

(limited to 'css_media_queries.mdwn')

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" :)
+
-- 
cgit v1.2.3