|author||Daniel Silverstone <email@example.com>||2017-02-04 09:41:13 +0000|
|committer||Daniel Silverstone <firstname.lastname@example.org>||2017-02-04 09:41:13 +0000|
Initial conversion from MediaWiki, 20170204
Diffstat (limited to 'css_media_queries.mdwn')
1 files changed, 116 insertions, 0 deletions
diff --git a/css_media_queries.mdwn b/css_media_queries.mdwn
new file mode 100644
@@ -0,0 +1,116 @@
+[[!meta title="Css media queries"]]
+**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.
+may also have a media attribute. though I don't recall if NetSurf
+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.
+**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
+**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
+*'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
+), 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 ;)
+- 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
+**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
+**jmb** "oops" :)