| 00:25 | <SimonSapin> | TabAtkins: can I assume a single "root box" generated by the root element? |
| 00:31 | <wilhelm> | zewt: I agree. |
| 00:57 | <gotwig> | hello folks |
| 00:58 | <gotwig> | What about a more hierachic selector model support for CSS 4? |
| 00:58 | <gotwig> | for relative paths..? |
| 00:59 | <gotwig> | and I also have a problem. Well, I do not know how to realize it properly but here is my idea: |
| 00:59 | <gotwig> | I want to make a dropdown slider window thing, that only happens when I press on a specific button |
| 00:59 | <gotwig> | now you can do that in CSS with different methods, but IMHO there is no method that fulfills the goal to 100% |
| 01:00 | <gotwig> | http://tympanus.net/Tutorials/CSSClickEvents/index.html |
| 01:01 | <gotwig> | I realized in my case the thing with a transform loop that is nearly endless |
| 01:01 | <gotwig> | the problem here is, you can't cancel that loop without a web scripting language. You can't cancel it with css, or apply other styles |
| 01:02 | <gotwig> | focus doesn't work for me as well, because when I focus a textbox in the div, the focus gets lost and I am back. |
| 01:02 | <gotwig> | target is ofcourse not a good idea as well. |
| 01:03 | <gotwig> | oh, there is the first one :X |
| 01:04 | <gotwig> | but with the first one, its hard to apply something like a blur out |
| 01:04 | <gotwig> | maybe I want to lose the focus when I leave that div |
| 01:05 | <gotwig> | oh, I can use the NOT right? |
| 10:55 | <Ms2ger> | annevk: please add a note to http://annevankesteren.nl/2011/06/creating-events that the old example doesn't work anymore |
| 11:03 | <Ms2ger> | annevk: and we should probably spec the untouchables from https://bugs.webkit.org/show_bug.cgi?id=68791#c14 |
| 13:16 | <annevk> | Hopefully MutationEvent can be avoided... |
| 13:38 | <annevk> | Ms2ger: fixed the blog post |
| 13:45 | <gsnedders> | Firefox blocking third party cookies? Huh. Wonder if they'll manage to do so without breaking too much. (Opera 10.50 did — most of the broken sites were Russian.) |
| 13:47 | <annevk> | I wonder if for XMLHttpRequest we should stop distinguishing user terminates request from network error... It's such a small special case and browsers typically don't have UI for it. |
| 14:01 | <annevk> | CORS-enabled fetch in HTML seems buggy with respect to redirects |
| 14:02 | <annevk> | E.g. cross-origin to data URL... |
| 14:30 | <gotwig> | hey ho |
| 14:30 | <gotwig> | so you talk about html5+ ? |
| 14:30 | <Philip`> | Occasionally |
| 14:31 | <gotwig> | I would be pleased to get your help :X |
| 14:31 | <gotwig> | so... why is :after not a property, but a pseudo class |
| 14:31 | <gotwig> | oh, eh, I can combine it with other pseudoclasses, right? |
| 14:32 | <gotwig> | I forgot that |
| 14:32 | <gotwig> | e.g p:hover:after{content: "Text" } |
| 14:32 | <gotwig> | right? |
| 14:33 | <gotwig> | ^css |
| 14:34 | <Badreddin> | yes |
| 14:34 | <Badreddin> | I just did it |
| 14:35 | <gotwig> | meaning the text only appers after I do a hover� |
| 14:35 | <gotwig> | ? |
| 14:35 | <Philip`> | gotwig: Do you mean why is it not "p:hover { after: "Text" }" or something? |
| 14:35 | <gotwig> | Philip`, yeah |
| 14:35 | <Badreddin> | yes, only on hover |
| 14:35 | <gotwig> | but I forgot that I can combine pseudo classes |
| 14:36 | <gotwig> | :after and :before are godlike features... |
| 14:36 | <Philip`> | I guess it's so you can do p:after { content: "Text"; color: #f0f; } etc, and apply arbitrary CSS to the aftered content |
| 14:37 | <gotwig> | works like ice cream ;D |
| 14:39 | <gotwig> | can you help me a bit here? |
| 14:39 | <gotwig> | http://bbm3h11bgo.bplaced.net/project/index.php |
| 14:39 | <gotwig> | I want that if the checkbox is checked, there should be Close before the label Test |
| 14:40 | <gotwig> | I used #toggle:checked:before label{ |
| 14:40 | <gotwig> | content: "Close"; |
| 14:40 | <gotwig> | color: white; |
| 14:40 | <gotwig> | } for that |
| 14:40 | <gotwig> | sry.. |
| 14:41 | <Philip`> | I'd expect it to be more like "#toggle:checked label:before" |
| 14:41 | <gotwig> | oh yeah |
| 14:41 | <gotwig> | I try that |
| 14:42 | <gotwig> | but It still doesnt work :X |
| 14:43 | <gotwig> | label:before works as expected, btw |
| 14:44 | <ronaldmansveld> | it's because label isn't a decendant, but a sibling of #toggle |
| 14:44 | <ronaldmansveld> | so use the sibling selector between the two ;) |
| 14:44 | <annevk> | gotwig: ::before/::after are pseudo-elements |
| 14:44 | <ronaldmansveld> | #toggle:checked + label:before |
| 14:45 | <annevk> | gotwig: they are not -classes and can only appear at the end of a selector |
| 14:45 | <gotwig> | why is it a sibling |
| 14:45 | <gotwig> | its a seperate tag, under the other, not inherited or what ever :X |
| 14:45 | <ronaldmansveld> | because they are next to each other in the sourcecode, the label is'nt contained by the input |
| 14:45 | <annevk> | if elements have the same parent they are siblings |
| 14:45 | <ronaldmansveld> | thanks annevk |
| 14:45 | <gotwig> | Works |
| 14:46 | <gotwig> | thX |
| 14:46 | <ronaldmansveld> | that was indeed the definition I was looking for :P |
| 14:46 | <annevk> | gotwig: see http://dom.spec.whatwg.org/#trees for more platform tree terminology |
| 14:46 | <gotwig> | thx |
| 14:46 | <gotwig> | do you see what I want to do? |
| 14:46 | <gotwig> | I want to realize a click > panel come down thing |
| 14:47 | <annevk> | use <details> |
| 14:47 | <gotwig> | can I replace content with css? |
| 14:47 | <annevk> | I think it's styleable to some extent |
| 14:48 | <gotwig> | hm, what ever, for now its enough |
| 14:48 | <gotwig> | * gives me all context right? |
| 14:49 | <gotwig> | so I've got #toggle:checked * #toppanel |
| 14:49 | <gotwig> | but that does nothing for me :/ I want that I can influence #toppanel, after toggle is checked |
| 14:49 | <gotwig> | toppanel is a grandparent of toggle |
| 14:50 | <annevk> | not without scripting |
| 14:50 | <gotwig> | why |
| 14:50 | <gotwig> | because I can't access the parent? |
| 14:50 | <ronaldmansveld> | it's not (yet) possible to style (grand)parents with CSS |
| 14:50 | <annevk> | there's no parent selector |
| 14:51 | <gotwig> | but I tought * would give me control over the whole css tree? |
| 14:51 | <annevk> | no |
| 14:51 | <annevk> | * matches any element |
| 14:51 | <ronaldmansveld> | I believe CSS4 will introduce a parentselector though, but that will take some time to be available |
| 14:51 | <gotwig> | any element in context of the current level or what? |
| 14:51 | <annevk> | yes |
| 14:51 | <annevk> | :checked and *:checked are equivalent |
| 14:51 | <gotwig> | and I also read about that with css4, the parent thing |
| 14:51 | <annevk> | #test and *#test are too |
| 14:52 | <gotwig> | that is sad ;/ |
| 14:52 | <gotwig> | I tought I could do it in css only |
| 14:52 | <gotwig> | but well, I add it maybe on the same div leve |
| 14:52 | <gotwig> | l |
| 14:52 | <gotwig> | and then positionate a bit |
| 14:53 | <gotwig> | labels for="" does not work on the whole tree, right? |
| 14:53 | <annevk> | it does |
| 14:53 | <ronaldmansveld> | it does, because the for will match on ID |
| 14:54 | <gotwig> | thats great |
| 14:54 | <gotwig> | so the user does not have to see the checkbox |
| 14:54 | <gotwig> | :> |
| 14:54 | <gotwig> | and I still can use good positions |
| 14:55 | <annevk> | it sounds like you're not solving this in entirely the right way, but have fun tinkering |
| 14:56 | <gotwig> | annevk, how would you do it in css only? |
| 14:56 | <gotwig> | I saw that here http://tympanus.net/Tutorials/CSSClickEvents/index.html |
| 14:58 | <gotwig> | do you can tell me on which level the checkbox has to be..? |
| 15:03 | <gotwig> | does that here work? https://github.com/Idered/cssParentSelector |
| 15:07 | <gotwig> | what about having to focuses? |
| 15:07 | <gotwig> | *two |
| 15:12 | <annevk> | gotwig: for general development questions #html5 is prolly a better channel |
| 15:12 | <gotwig> | ok. |
| 15:13 | <annevk> | it's fine to ask questions here, but people here are generally more focused on developing standards |
| 15:35 | <annevk> | Hmm, merging Fetch and CORS gets interesting... |
| 15:37 | <annevk> | The problem being that Fetch ignores origin completely. So e.g. if we want to support <script> but also allow the response to be annotated with CORS, we need to keep track of that during the request, but not fail if CORS fails... |
| 15:37 | <annevk> | But, that does not work if the request is something that CORS cannot do without preflight. But I guess we don't have such requests currently as that would kinda defeat the point of CORS. |
| 15:38 | <gotwig> | annevk, can you help me with CSS4? |
| 15:40 | <annevk> | gotwig: http://www.xanthir.com/b4Ko0 |
| 15:40 | <annevk> | gotwig: I don't really know much about the checkbox tricks people employ these days I'm afraid |
| 15:40 | <gotwig> | the following #toppanel! > #toggle:checked { top:0px } I use http://demo.idered.pl/jQuery.cssParentSelector/ |
| 15:41 | <gotwig> | I want that if the user checks toggle, toppanel should change its property to top:0px |
| 15:42 | <gotwig> | is that in theory, the right code? |
| 15:42 | <annevk> | are you including the script as that page instructs? |
| 15:43 | <annevk> | I believe I told you before that without script there's no selecting of parents |
| 15:46 | <gotwig> | I included the script |
| 15:46 | <gotwig> | in the .html page, where I also load the css fie |
| 15:46 | <gotwig> | *file |
| 15:47 | <annevk> | and jQuery? |
| 15:47 | <gotwig> | yes |
| 15:48 | <annevk> | well should work then I suppose |
| 15:48 | <gotwig> | on the html page, not on the css file... I dont know if I have to load it somehow first, load it into an object or so.. |
| 15:48 | <gotwig> | I grab the tests. |
| 15:48 | <annevk> | nah, looks like the script fetches external style sheets |
| 15:49 | <annevk> | which seems like a waste, but I guess that's webdev these days |
| 15:50 | <gotwig> | not good enough for a web browser implementation ;) is there more work being done on the subject thing, or on the parent selector? |
| 15:50 | <gotwig> | I heard that with a subject pseudo class thingy you would be able to do more then with just a parent selector |
| 15:53 | <annevk> | I don't follow www-style closely |
| 16:17 | <gotwig> | annevk, I got it working |
| 16:17 | <gotwig> | and I am very depressed now... important is not able to handle a property line that does not contain an ; as a charachter? |
| 16:20 | <annevk> | So I'm sketching out the Fetch logic in some pseudo-Python, and it's complicated :-( |
| 16:22 | <zewt> | wow, pretty terrible firefox console window bug: it's collapsing lines even when they aren't the last line |
| 16:23 | <zewt> | in fact, it's collapsing them when they aren't even on screen, so i thought something was fixed (because i didn't see the warning) wasn't |
| 16:26 | GPHemsley | recalls experiencing that a lot |
| 16:26 | <GPHemsley> | It also collapses any line that is identical |
| 16:26 | <GPHemsley> | which can be confusing |
| 16:27 | <zewt> | pretty broken behavior, imo (but anyway I'm back in Chrome which is much saner) |
| 16:28 | <zewt> | wow this parent selector code is ... |
| 16:28 | <zewt> | j && (parsed += ','); |
| 16:28 | <zewt> | i smell a perl programmer |
| 16:30 | <zewt> | also all variables var'd at the top of the block, somebody with some really bad habits left over from old C as well it seems |
| 16:33 | <zewt> | not sure this is a hack i'd ever want to actually use--don't think i trust anything that parses my CSS with a bunch of unreadable regexes and modifies them |
| 16:33 | <zewt> | /[\w\s\.\-\:\=\'\*\|\?\^\+\/\\;#%]+\}{1}/ \i\ \c\a\n\'\t\ \r\e\a\d\ \t\h\i\s |
| 16:38 | <zewt> | https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#keyboard-101 wow this is ... a bit insane |
| 16:43 | <annevk> | http://wiki.whatwg.org/wiki/Fetch#Python_pseudo-code for those interested |
| 16:43 | <annevk> | main bit is def fetch() |
| 16:44 | <zewt> | (whew, looks like none of those keyboard pictures are normative) |
| 16:44 | <annevk> | zewt: JavaScript hoists variables to the top of the block so you might as well declare them there |
| 16:44 | <zewt> | no way, that makes a mess of code |
| 16:45 | <zewt> | have a bunch of declarations at the top (where you have no idea what they're all for), and variables below where you can't tell if they're actually declared as locals (because it's all up top) |
| 16:48 | <zewt> | (i definitely wish strict had fixed that design screwup, though, and made vars local to the enclosing block) |
| 16:51 | <zewt> | annevk: file: is usually a hard error for xhr, but for things like <img> it just taints, right? |
| 16:52 | <annevk> | afaik file does not work cross-origin |
| 16:53 | <zewt> | <img src=foo.jpg> works for me on file: |
| 16:53 | <zewt> | (in chrome and FF) |
| 16:53 | <zewt> | it's just tainted so you can't use it with canvas, etc |
| 16:53 | <annevk> | that's same-origin though |
| 16:54 | <zewt> | all file: requests are cross-origin, right? |
| 16:54 | <zewt> | (each file is its own origin) |
| 16:55 | <zewt> | pretty sure that xhr would fail for the same url |
| 16:55 | <annevk> | ah yeah, maybe file requires a bit more special casing then |
| 16:55 | <annevk> | I think some browsers might scope origin to a directory, but I'm not sure |
| 16:57 | <gsnedders> | annevk: directory or its children is what WebKit does, IIRC |
| 16:57 | <zewt> | chrome is per-file i'm pretty sure |
| 16:57 | <annevk> | but anyway, file: is the least important |
| 16:57 | <zewt> | since they don't want a script in the root directory to be able to access the whole HDD |
| 16:57 | <annevk> | it's going to be by and large platform-dependent |
| 16:58 | <annevk> | and implementation |
| 16:58 | <gsnedders> | zewt: It's the document path, not the script path, that matters. |
| 16:58 | <zewt> | not following |
| 16:58 | <zewt> | (they're the same for an html file with a <script>) |
| 16:59 | <annevk> | just assume s/NetworkError()/ImplementationSpecific()/ for that line |
| 16:59 | <zewt> | also you can't access stuff even in the same directory, eg. so if you drop foo.html into ~ it can't read .wgetrc and read passwords or whatever |
| 17:01 | <gsnedders> | Some browser has that behaviour, at least :P |
| 17:02 | <zewt> | i don't think any current desktop browser allows xhr on file: at all |
| 17:02 | <zewt> | i think chrome used to, since I vaguely remember being irritated when it stopped working |
| 17:05 | <zewt> | annevk: file: aside, it looks like Chrome, at least, doesn't allow cross-origin xhr for anything at all except http/https |
| 17:06 | <zewt> | XMLHttpRequest cannot load file:///E:/temp/foo. Cross origin requests are only supported for HTTP. |
| 17:06 | <zewt> | it can't even load about:blank, which seems lame |
| 17:07 | <zewt> | or data: |
| 17:08 | <annevk> | zewt: that's a new feature |
| 17:08 | <annevk> | kinda |
| 17:08 | <zewt> | data: isn't exactly new, heh |
| 17:09 | <annevk> | well that you can load it through XHR was only added recently |
| 17:09 | <annevk> | this is adding about:blank |
| 17:09 | <annevk> | and about:unicorn |
| 18:00 | <annevk> | So if you do a request to a cross-origin URL for which the response is a redirect (that opts into CORS) to a data: URL. Should we expose the data: URL given that the redirected opted in? |
| 18:11 | GPHemsley | misses the 'Alternate "101" Keyboard Layout' |
| 18:24 | <GPHemsley> | I take it UI Events is a No Scroogling Zone? |
| 18:31 | <annevk> | What does that mean? |
| 18:49 | <GPHemsley> | annevk: It's a reference to commercials Outlook is running against Google in the U.S. |
| 18:49 | <GPHemsley> | annevk: You might not have seen them. |
| 18:50 | <GPHemsley> | annevk: http://www.computerworld.com/s/article/9236916/Microsoft_adopts_advocacy_tactics_to_scroogle_Google_in_attack_campaign |
| 19:04 | <annevk> | GPHemsley: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm is the location anyway |
| 20:12 | <SimonSapin> | So, @page inherits from the root, and viewport units are based on the page size. How do we resolve this without breaking some use cases? :root { font-size: 1vw } @page { width: 50em } |
| 20:17 | <GPHemsley> | SimonSapin: Does it make sense to use viewport lengths for font-size? |
| 20:17 | GPHemsley | gets déjà vu. |
| 20:18 | <SimonSapin> | GPHemsley: some people like it, for slides: http://css-tricks.com/viewport-sized-typography/ |
| 20:18 | <SimonSapin> | I think the use case is interesting |
| 20:18 | <SimonSapin> | but so is em for page margins |
| 20:18 | <SimonSapin> | and so is @page inheriting from root |
| 20:19 | <GPHemsley> | "For use with font-size, I guess it's one "letter" that takes on that size, but as we know, in non-mono-spaced fonts the width of a letter is rather arbitrary. I find you just need to tweak around with the values to get it how you want it. Which is basically what we do anyway, right?" |
| 20:19 | <GPHemsley> | That seems like it opens things up to be really complicated. |
| 20:20 | <SimonSapin> | on screen it’s fine, you know the size of the viewport before looking at anything CSS |
| 20:21 | <SimonSapin> | on Paged Media we defined the "viewport" to be the content area of the first page, … whose size can be controlled in CSS |
| 20:21 | <SimonSapin> | and now we are so screwed :) |
| 20:21 | <GPHemsley> | and what happens with fallback fonts? |
| 20:21 | <GPHemsley> | IDK, it just seems like it'd be easier for everyone if they were just disallowed |
| 20:22 | <SimonSapin> | font-size is just a length, independant of the face |
| 20:23 | <GPHemsley> | and it also makes things impossible to read on really small windows |
| 20:23 | <GPHemsley> | sure, it fits in the frame, but to what end? |
| 20:24 | <GPHemsley> | http://css-tricks.com/examples/ViewportTypography/ |
| 20:24 | <GPHemsley> | try resizing the window |
| 20:24 | <SimonSapin> | maybe we could have defined this differently, but that ship has sailed |
| 20:24 | <GPHemsley> | meh |
| 20:24 | GPHemsley | doesn't own a boat |
| 20:25 | <SimonSapin> | these issues are all valid, but the behavior is still well-defined |
| 20:25 | <SimonSapin> | not so on Paged Media :/ |
| 20:27 | <GPHemsley> | So... why does @page inherit from :root? |
| 20:27 | <GPHemsley> | shouldn't @page = viewport? |
| 20:29 | <SimonSapin> | Page-margin boxes (that contain text) inherit from @page, so it’s useful to get the root’s font "for free" |
| 20:29 | <SimonSapin> | Also 'direction' and 'writing-modes' affect some stuff of left vs. right page, again nice to get the values from the root |
| 20:32 | <GPHemsley> | Perhaps there needs to be some distinction between "paper" and "page" |
| 20:33 | <GPHemsley> | Or, actually |
| 20:34 | <GPHemsley> | shouldn't it be @page > :root > page-margin box ? |
| 20:34 | <SimonSapin> | there only one root element, but multiple page boxes |
| 20:35 | <GPHemsley> | there should be some distinction between what the physical page requirements are and what the contents of the page are |
| 20:35 | <SimonSapin> | when painting it somewhat like @page > { :root, page-margin boxes } |
| 20:35 | <SimonSapin> | but the cascade is :root element > @page > page-margin boxes |
| 20:36 | <SimonSapin> | maybe @page inheriting from the root is what we’ll end up removing |
| 20:36 | <SimonSapin> | which, by the way, is well defined as long as you don’t have viewport units |
| 20:36 | <GPHemsley> | Yeah, I think :root should inherit from @page |
| 20:36 | <GPHemsley> | which should not preclude page-margin boxes from inheriting from :root |
| 20:37 | <GPHemsley> | it's best to think about it physically, I think |
| 20:38 | <GPHemsley> | most fundamentally, you have a sheet of paper whose dimensions and properties do not change, no matter what is printed on it |
| 20:39 | <GPHemsley> | maybe page-margin boxes shouldn't inherit from :root |
| 20:39 | <SimonSapin> | page dimensions do change: table { page: wide } @page wide { size: A4 landscape } @page { size: A4 portrait /* default */ } |
| 20:39 | <SimonSapin> | different pages can have different styles |
| 20:39 | <GPHemsley> | well |
| 20:40 | <GPHemsley> | that changes the sheet of paper, too, doesn't it? |
| 20:40 | <GPHemsley> | that is, tables will get a new sheet with that style, won't they? |
| 20:40 | <SimonSapin> | it could, that’s undefined |
| 20:40 | <SimonSapin> | although in this case it’s expected to only rotate |
| 20:40 | <GPHemsley> | how do you rotate only part of a page? |
| 20:41 | <SimonSapin> | no, changing page type causes a forced page break |
| 20:41 | <GPHemsley> | right, exactly |
| 20:41 | <GPHemsley> | so dimensions may change from page to page |
| 20:41 | <GPHemsley> | but they don't change within the page |
| 20:43 | <GPHemsley> | also, in that case, wouldn't that mean that the text size would change because the width/height would change? |
| 20:43 | <GPHemsley> | the text size in the table, that is |
| 20:43 | <GPHemsley> | (if you used viewport units to size the font) |
| 20:45 | <GPHemsley> | and what happens if multiple pages are printed on a single sheet? |
| 20:45 | <GPHemsley> | (that may be an orthogonal question) |
| 20:46 | <SimonSapin> | viewport units in paged media are only based on the first page |
| 20:46 | <GPHemsley> | ah, right |
| 20:46 | <GPHemsley> | you said that |
| 20:46 | <SimonSapin> | implementations don’t want a set of computed value per page |
| 20:47 | <SimonSapin> | another option would have been to make them like percentages, only resolved during layout. But we resolved on the first one |
| 20:48 | <GPHemsley> | what document(s) can I use as reference in this discussion? |
| 20:49 | <GPHemsley> | how do you determine what the first page is? |
| 20:49 | <GPHemsley> | what if a table is on the first page? |
| 20:49 | <SimonSapin> | eh … its a bit scattered on www-style and conf call minutes |
| 20:50 | <GPHemsley> | does that mean that all the subsequent pages use text sized on landscape instead of portrait? |
| 20:50 | <GPHemsley> | ah |
| 20:50 | <GPHemsley> | what's the background document (spec)? |
| 20:51 | <SimonSapin> | after the table you go to the parent’s or next sibling’s page type |
| 20:51 | <SimonSapin> | http://dev.w3.org/csswg/css3-page/ |
| 20:51 | <SimonSapin> | if there is no content before the table (roughly), the first page is wide |
| 20:51 | <GPHemsley> | for the "first page" calculation? |
| 20:51 | <GPHemsley> | for the viewport, I mean |
| 20:52 | <SimonSapin> | http://dev.w3.org/csswg/css3-values/#viewport-relative-lengths |
| 20:52 | <SimonSapin> | "initial containing block" is defined in http://dev.w3.org/csswg/css3-page/#page-box-page-rule |
| 20:53 | <SimonSapin> | interactions of viewport units and @page are not yet defined (that’s my issue list) |
| 20:54 | <GPHemsley> | page box = printable area? |
| 20:55 | <SimonSapin> | hum, mostly |
| 20:57 | <GPHemsley> | OK, so, each sheet of paper has a single page box? |
| 20:57 | <GPHemsley> | (assuming one page per sheet) |
| 20:57 | <SimonSapin> | yes |
| 20:58 | <SimonSapin> | although other transfer types are allowed: http://dev.w3.org/csswg/css3-page/#transfer-possibilities |
| 20:58 | <GPHemsley> | @page > @page :left, @page :right ? |
| 21:02 | <SimonSapin> | @page {} applies to all pages, but with weaker specificity than @page :left {} which applies only to left pages |
| 21:02 | <GPHemsley> | is that different from inheritance? |
| 21:04 | <GPHemsley> | does the "initial containing block" take on the properties of whichever of :left and :right is first? |
| 21:04 | <SimonSapin> | I guess you could view it kind of like inheritance … but it is more like different selectors matching the same element |
| 21:04 | <SimonSapin> | the usual cascading rules apply |
| 21:05 | <GPHemsley> | ...which question was that a response to? |
| 21:05 | <SimonSapin> | with source, order specificity, !important, stylesheet origin, etc. |
| 21:05 | <SimonSapin> | response to "is that different from inheritance" |
| 21:05 | <GPHemsley> | ah, ok |
| 21:06 | <SimonSapin> | ICB is basically the used values of the 'width' and 'height' properties of the first page, after cascading and resolving 'auto' values |
| 21:07 | <GPHemsley> | so, if :left and :right wind up having different widths/heights, then the width/height of the "first page" (and, thus, the ICB) would depend on whether the "first page" was :left or :right? |
| 21:08 | <SimonSapin> | yes |
| 21:08 | <SimonSapin> | which depends on writing mode and direction |
| 21:08 | <GPHemsley> | hmm |
| 21:09 | <SimonSapin> | http://dev.w3.org/csswg/css3-page/#progression |
| 21:09 | <SimonSapin> | at least the default depends on that |
| 21:09 | <SimonSapin> | authors can switch with eg. :root { break-before: left } |
| 21:09 | <SimonSapin> | (there is no printed page before that "page break") |
| 21:11 | <GPHemsley> | right |
| 21:11 | <GPHemsley> | hmm |
| 21:12 | <GPHemsley> | but what does that mean if you have: table { page: wide } @page wide { size: A4 landscape } @page { size: A4 portrait /* default */ } |
| 21:13 | <GPHemsley> | and then :root > table:first-child ? |
| 21:13 | <SimonSapin> | then the first page is A4 landscape |
| 21:13 | <GPHemsley> | does that mean the "first page" is now @page wide ? |
| 21:13 | <SimonSapin> | yes |
| 21:15 | <GPHemsley> | is it a good idea to allow that to control how the viewport units are calculated? |
| 21:15 | <GPHemsley> | or is that part of the question we're trying to answer? |
| 21:15 | <SimonSapin> | interesting point |
| 21:16 | <SimonSapin> | "ICB = first page" is somewhat arbitrary |
| 21:16 | <GPHemsley> | so, we always have @page :left and @page :right |
| 21:16 | <GPHemsley> | oftentimes they are the same |
| 21:16 | <GPHemsley> | sometimes they are different |
| 21:16 | <GPHemsley> | page progression determines which one is "first" |
| 21:17 | <SimonSapin> | viewport units being based on the first page makes the feature somewhat useless when page size varies. But anything else has too much implementation cost |
| 21:17 | <GPHemsley> | I think that's about as far as you should go before you determine viewport units |
| 21:17 | <GPHemsley> | oh |
| 21:17 | <GPHemsley> | too much of an exception to the rule? |
| 21:18 | <SimonSapin> | the ICB is based on 'width' and 'height' in @page. But if that is 'auto', it’s based on margin-*, border-*-width, padding-*, and size |
| 21:18 | <SimonSapin> | do you mean not inherit from :root? |
| 21:20 | <GPHemsley> | would there ever be a time when :root differs from whatever the first element is? |
| 21:20 | <GPHemsley> | e.g. on an HTML page, where :root differs from html |
| 21:21 | <SimonSapin> | :root is short for "the root element" |
| 21:21 | <GPHemsley> | so no? |
| 21:21 | <SimonSapin> | in HTML, that’s always <html> AFAIK |
| 21:22 | <GPHemsley> | which parts of determining what the "first page" is are set in stone? |
| 21:23 | <SimonSapin> | none, I guess |
| 21:23 | <SimonSapin> | set in clay that has not completely dried yet, maybe? :p |
| 21:24 | <GPHemsley> | ah, so what implementation cost are you referring to? |
| 21:27 | <SimonSapin> | cost of treating viewport units like percentages so that they can have a different value on each page |
| 21:27 | <GPHemsley> | oh |
| 21:27 | <GPHemsley> | I'm not arguing to allow their value to change per page |
| 21:27 | <SimonSapin> | yeah, the WG resolved against that |
| 21:28 | <GPHemsley> | just to allow their value to be based on a sane page |
| 21:29 | <GPHemsley> | I'm thinking it should be based on the size of whichever of :left or :right is first |
| 21:29 | <GPHemsley> | but before :first |
| 21:29 | <SimonSapin> | like, based on an hypothetical "unnamed" page that does not match any pseudo-class? |
| 21:29 | <GPHemsley> | sort of, yeah |
| 21:30 | <GPHemsley> | kind of, based on whatever :first is inheriting from |
| 21:30 | <SimonSapin> | "whichever of :left or :right is first" that depends on the 'direction' property on :root |
| 21:30 | <GPHemsley> | is that a problem? |
| 21:30 | <SimonSapin> | it’s not really inheriting |
| 21:30 | <SimonSapin> | not sure yet if that would work |
| 21:31 | <GPHemsley> | well, :left and :right both get their default values from @page, right? |
| 21:31 | <SimonSapin> | hum, not really |
| 21:31 | <GPHemsley> | then page progression and whatnot decides which of :left and :right becaomes :first |
| 21:31 | <GPHemsley> | oh |
| 21:32 | <GPHemsley> | specificity |
| 21:32 | <GPHemsley> | that's involved in here somewhere |
| 21:33 | <SimonSapin> | declarations for pages are qualified by a page selector which as specificity. The cascade picks a "winning" declaration for every property of every page based on a combination of stylesheet "origin" (UA, author, user), !important, specificity, and source order |
| 21:33 | <SimonSapin> | for selectors that match |
| 21:33 | <SimonSapin> | it’s the same cascade as on elements |
| 21:34 | <GPHemsley> | well, I'm thinking viewport units are determined at (0,0,x), where x is the highest number in context |
| 21:34 | <GPHemsley> | (if that even makes sense in the terminology) |
| 21:35 | <SimonSapin> | highest number? |
| 21:35 | <GPHemsley> | yeah, maybe it doesn't make sense |
| 21:36 | <SimonSapin> | Not sure what you mean |
| 21:38 | <GPHemsley> | can g or h every be >1 ? |
| 21:39 | GPHemsley | is not sure where "This is 0 or 1. " applies |
| 21:39 | <SimonSapin> | no |
| 21:40 | <GPHemsley> | ok |
| 21:40 | <SimonSapin> | the syntax only allows zero or one page name per selector |
| 21:40 | <SimonSapin> | is the note unclear? |
| 21:40 | <GPHemsley> | yeah, a little |
| 21:40 | <SimonSapin> | how would you phrase it? |
| 21:40 | <GPHemsley> | the first few times I read it, I thought it applied to f, not g and h |
| 21:40 | <SimonSapin> | oh, sorry I misread you |
| 21:40 | <SimonSapin> | it applies to f, not g or h |
| 21:40 | <GPHemsley> | oh |
| 21:41 | <GPHemsley> | so, wait |
| 21:41 | <GPHemsley> | when would you have, e.g., (0,0,2)? |
| 21:42 | <SimonSapin> | "Given the syntax of page seletors, <var>f</var> can only ever be 0 or 1." Better? |
| 21:43 | <GPHemsley> | Sure, but now I still don't have an answer to the question I was really looking to answer. :P |
| 21:43 | <SimonSapin> | (0,0,2) with @page :left:left (which is silly) or @page :left:right (which never matches.) But they are allowed |
| 21:44 | <SimonSapin> | maybe in the future we’ll add more pseudo-classes |
| 21:44 | <SimonSapin> | :blank was added recently |
| 21:44 | <GPHemsley> | so, @page :left:left will override @page :left ? |
| 21:44 | <SimonSapin> | yes |
| 21:44 | <SimonSapin> | stronger specificity |
| 21:44 | <GPHemsley> | that seems strange |
| 21:44 | <GPHemsley> | but not really the issue at hand |
| 21:44 | <SimonSapin> | table:first-child:first-child does the same |
| 21:45 | <GPHemsley> | also strange |
| 21:45 | <GPHemsley> | but anyway |
| 21:46 | <GPHemsley> | viewport units should be calculated according to (0,0,x-1), where x is the specificity of the highest on the page |
| 21:46 | <GPHemsley> | so, @page :first { font-size: 1vw } should be 1% of the width of @page :left:left |
| 21:47 | <GPHemsley> | (assuming @page :left:left specified) |
| 21:47 | <GPHemsley> | which is perhaps still an abuse of the terminology |
| 21:47 | <GPHemsley> | but hopefully it makes sense this time |
| 21:47 | <SimonSapin> | I’m still not sure how you determine X |
| 21:48 | <GPHemsley> | ok, hmm |
| 21:49 | <GPHemsley> | a page with a higher specificity inherits the properties of the lower specificities that also match, correct? |
| 21:49 | <GPHemsley> | (and then can override them) |
| 21:49 | <SimonSapin> | "inherit" is not the right word, but I see what you mean |
| 21:51 | <SimonSapin> | the proposal I’m writing up for www-style is more like: only consider @page rules without a selector for determining the viewport units. |
| 21:52 | <GPHemsley> | but aren't pseudo-classes selectors? |
| 21:52 | <GPHemsley> | s/classes/pages/ if you like |
| 21:52 | <SimonSapin> | "without a selector" is @page {} only |
| 21:53 | <GPHemsley> | so, no difference/dependence on :left vs. :right ? |
| 21:53 | <SimonSapin> | and pages don’t have specificity, selectors do. A given page *matches* a subset of all selectors. We get a bunch of declarations sorted by specificity of the matched selector |
| 21:53 | <SimonSapin> | yes |
| 21:53 | <GPHemsley> | yeah, I like that better |
| 21:54 | <GPHemsley> | but I thought that was bogged down by interactions with :root or something? |
| 21:54 | <GPHemsley> | (surely there was a reason I was led away from that proposal in my thinking...) |
| 21:55 | <SimonSapin> | that helps with part of the issue that you pointed out (and I hadn’t seen before:) the size of the actual first page depends on a lot of stuff, including named pages |
| 21:55 | <SimonSapin> | We want something like a "default" page |
| 21:55 | <GPHemsley> | right |
| 21:55 | <SimonSapin> | but that doesn’t change the circular definition of viewport units vs. page size |
| 21:56 | <GPHemsley> | remind me, why not? |
| 21:56 | <SimonSapin> | for that , sanest way out I see is change @page to not inherit from the root. Which is sad, but I don’t see better |
| 21:57 | <GPHemsley> | yeah, I still think that'd be more intuitive |
| 21:57 | <SimonSapin> | consider @page { width: 50vw } |
| 21:57 | <SimonSapin> | the width is 50% of itself |
| 21:57 | <GPHemsley> | what about size? |
| 21:58 | <SimonSapin> | when width is 'auto', its used value is size minus margins, borders and paddings |
| 21:58 | <SimonSapin> | (size is the default containing block of page boxes) |
| 21:58 | <GPHemsley> | what does that have to do with viewport? :P |
| 21:58 | <GPHemsley> | oh |
| 21:59 | <SimonSapin> | viewport units are proportional to the "initial containing block" which is effectively the used 'width' and 'height' of some page box |
| 22:00 | <SimonSapin> | so what we can do is declare that such units are invalid in 'width' and some other properties in @page |
| 22:00 | <SimonSapin> | the declarations are ignored |
| 22:00 | <SimonSapin> | but if font-size is based of viewport units, then em and other font-based units also indirectly depend on the ICB |
| 22:01 | <GPHemsley> | what would happen if @page viewport units were declared in reference to size? |
| 22:01 | <GPHemsley> | (or can you only have one definition of viewport units?) |
| 22:01 | <SimonSapin> | they would behave very differently than on screen |
| 22:01 | <GPHemsley> | ah |
| 22:02 | <GPHemsley> | would they, though? |
| 22:02 | <SimonSapin> | we want 100vw to be the same as `width: 100%` on the root |
| 22:02 | <GPHemsley> | what happens for :root { width: 50vw } ? |
| 22:02 | <SimonSapin> | (module scrollbars on screen …) |
| 22:02 | <SimonSapin> | then the root is smaller than the ICB |
| 22:02 | <GPHemsley> | right |
| 22:02 | <SimonSapin> | the ICB is the root’s own containing block |
| 22:03 | <GPHemsley> | size > @page > :root |
| 22:04 | <GPHemsley> | screen resolution > browser window > :root |
| 22:06 | <SimonSapin> | as in "bigger than"? |
| 22:06 | <SimonSapin> | yes, unless you have negative margins :) |
| 22:06 | <GPHemsley> | yeah, and also "contains" |
| 22:06 | <GPHemsley> | so what if you do? |
| 22:07 | <SimonSapin> | you could have :root wider than the page box |
| 22:07 | <SimonSapin> | width: 120% |
| 22:07 | <GPHemsley> | but then it overflows |
| 22:07 | <SimonSapin> | yes |
| 22:07 | <SimonSapin> | anyway, yes it’s conceptually contained that way |
| 22:08 | <GPHemsley> | but I mean, if you have :root { width: 120vw } |
| 22:08 | <GPHemsley> | what happens on screen? |
| 22:08 | <SimonSapin> | scrollbars, I suppose |
| 22:08 | <GPHemsley> | right |
| 22:08 | <GPHemsley> | because it overflows |
| 22:08 | <SimonSapin> | same with 120% |
| 22:09 | <GPHemsley> | but that doesn't redefine vw |
| 22:09 | <SimonSapin> | yes |
| 22:09 | <GPHemsley> | the difference between screen and page in this case is that you can't style "browser window" like you can with @page |
| 22:09 | <SimonSapin> | nothing in CSS can change the viewport on screen |
| 22:09 | <GPHemsley> | exactly |
| 22:10 | <GPHemsley> | but if you could, you'd predict @viewport { width: 100vw } to be relative to the screen resolution, wouldn't you? |
| 22:10 | <SimonSapin> | oh, wait, http://dev.w3.org/csswg/css-device-adapt/ |
| 22:10 | <GPHemsley> | (perhaps @window would be better) |
| 22:10 | <SimonSapin> | @viewport is a thing |
| 22:11 | <GPHemsley> | does it fall into this analogy? (I hope) |
| 22:11 | <SimonSapin> | @viewport is described as similar to @page |
| 22:12 | <GPHemsley> | does it handle viewport units? |
| 22:12 | <GPHemsley> | (I'm not seeing that it does) |
| 22:12 | <GPHemsley> | <viewport-length> = auto | device-width | device-height | <length> | <percentage> |
| 22:13 | <GPHemsley> | <length> |
| 22:13 | <GPHemsley> | A positive absolute or relative length. |
| 22:13 | <SimonSapin> | "Viewport lengths (vw, vh, vmin, vmax) are relative to the initial viewport." |
| 22:13 | <GPHemsley> | initial viewport |
| 22:13 | <GPHemsley> | This refers to the viewport before any UA or author styles have overridden the viewport given by the window or viewing area of the UA. Note that the initial viewport size will change with the size of the window or viewing area. |
| 22:14 | <GPHemsley> | aka @page without selectors |
| 22:14 | <SimonSapin> | we could have viewport units inside @page be based on the default page size, like media queries |
| 22:14 | <GPHemsley> | wasn't that what I was saying? :P |
| 22:15 | <SimonSapin> | yeah, I just noticed :p |
| 22:15 | <SimonSapin> | except default without considering stylesheets at all, even @page without a selector |
| 22:15 | <GPHemsley> | right |
| 22:16 | <SimonSapin> | be vw can still "leak" from :root through inheritance |
| 22:16 | <GPHemsley> | remind me what the inheritance is now? |
| 22:17 | <SimonSapin> | the default font-size in an element is that of its parent |
| 22:17 | <SimonSapin> | :root is considered the "parent" of page boxes for the purpose of the cascade (determining computed values of properties) |
| 22:18 | <GPHemsley> | so viewport units in :root would be based on the size of the paper? |
| 22:18 | <GPHemsley> | that doesn't seem so bad |
| 22:19 | <SimonSapin> | hum, not quite |
| 22:20 | <SimonSapin> | the point is that vw inside @page would be based of the UA’s default (eg. always A4 portrait minus 2cm margins, in WeasyPrint) even if stylesheets specify something else |
| 22:20 | <GPHemsley> | ah |
| 22:21 | <GPHemsley> | is that bad? |
| 22:22 | <GPHemsley> | (consider that the viewport is not equal to the browser window, because of toolbars and the like) |
| 22:24 | <SimonSapin> | no, that’s actually better than making the declarations invalid |
| 22:24 | <GPHemsley> | yeah |
| 22:24 | <SimonSapin> | well, I think so |
| 22:24 | <GPHemsley> | I agree |
| 22:24 | <GPHemsley> | I never wanted to do that ;) |
| 22:24 | <GPHemsley> | oh, except in the beginning |
| 22:24 | <SimonSapin> | invalid is what CSS WG kind of agreed on so far |
| 22:24 | <GPHemsley> | where I was throwing them all away |
| 22:24 | <GPHemsley> | oh |
| 22:24 | <GPHemsley> | well |
| 22:24 | <SimonSapin> | but not a formal resolution |
| 22:24 | <GPHemsley> | they didn't spend the last two hours thinking it through |
| 22:24 | <SimonSapin> | that can be changed |
| 22:24 | <GPHemsley> | :P |
| 22:25 | <SimonSapin> | (although even resolutions can be changed by another resolution :p) |
| 22:25 | <GPHemsley> | so... did we settle it all? |
| 22:26 | <SimonSapin> | I raised this issue months ago, and I just had to ideas that I didn’t see before ;) |
| 22:26 | <GPHemsley> | :) |
| 22:26 | <SimonSapin> | erf, I meant *you* just had *two* ideas |
| 22:27 | <GPHemsley> | it's easy to think outside the box when you have no idea where the box is |
| 22:27 | <GPHemsley> | (no pun intended) |
| 22:27 | <SimonSapin> | hehe |
| 22:29 | <SimonSapin> | one point remains, though: |
| 22:29 | <SimonSapin> | does @page never inherit properties from the root element, or is that only for the purpose of determining viewport units? |
| 22:30 | <GPHemsley> | I think it would be more intuitive if it were never |
| 22:30 | <GPHemsley> | because, to me, the root element is a child of the page |
| 22:30 | <GPHemsley> | contained within the page |
| 22:30 | <GPHemsley> | however you want to phrase it |
| 22:33 | <SimonSapin> | each fragment of the root box is inside the page box, yes |
| 22:33 | <SimonSapin> | but there is only one root element |
| 22:33 | <SimonSapin> | (to rule them all) |
| 22:33 | <GPHemsley> | root element > root boxes? |
| 22:33 | <SimonSapin> | And the cascade (where inheritance happens) needs to happen before layout (where page breaks happen) |
| 22:34 | <SimonSapin> | elements generate boxes based on the 'display' property, and these boxes are "fragmented" at line breaks, page breaks, column breaks, etc. |
| 22:35 | <GPHemsley> | and remind me, what kind of stuff would get inherited from :root by @page? |
| 22:36 | <SimonSapin> | potentially any properties |
| 22:37 | <SimonSapin> | some like font-size are inherited by default |
| 22:37 | <SimonSapin> | any property can accept the 'inherit' keyword |
| 22:37 | <GPHemsley> | ah, right |
| 22:37 | <SimonSapin> | so this is valid, although crazy: :root { margin: 10vw } @page { margin: inherit } |
| 22:38 | <GPHemsley> | and according to our new definition, what is that vw relative to? |
| 22:39 | <GPHemsley> | or is it invalid? |
| 22:39 | GPHemsley | hopes you have this all written down already |
| 22:39 | <SimonSapin> | yes, I’m about to send it to www-style |
| 22:40 | <SimonSapin> | with what we discussed: `margin: inherit` has no inherited value, so the initial value is used. That is 0, for margin. |
| 22:40 | <SimonSapin> | 10vw is based on an hypothetical "default" page |
| 22:40 | <GPHemsley> | given that I think we wrote defined viewport units without reference to inheritance, it's probably OK to leave the :root/@page inheritance as is for now |
| 22:40 | <GPHemsley> | -wrote |
| 22:41 | <SimonSapin> | if you specify a page size on both :left and :right, no page will have the "default" size |
| 22:41 | <GPHemsley> | but the viewport units still will |
| 22:44 | <SimonSapin> | Sent: http://lists.w3.org/Archives/Public/www-style/2013Feb/0668.html |
| 22:45 | <GPHemsley> | Geez, that whole discussion distilled into that little e-mail? |
| 22:46 | <GPHemsley> | But cool |
| 22:46 | GPHemsley | should probably get on www-style |
| 22:46 | <GPHemsley> | anyway, I'm gonna head out |
| 22:46 | <GPHemsley> | if anything interesting happens, let me know |
| 22:46 | <GPHemsley> | (I'll let you know if/when I subscribe to www-style) |
| 22:46 | <SimonSapin> | thanks again GPHemsley |
| 22:46 | <GPHemsley> | sure thing :) |