I do care if stuff gets screwed up when a window is unmaximised or a device rotated ofc. I doubt many people care about smooth resizes. Actually, if Webkit and MSHTML had just added the equiv of the javascript hack in that testcase (force some sort of recalculate everything every 200ms or so if the viewport is different from the size it was previously) I'd be quite fine w/ that. This approach could be optimized further (in particular, by maintaining a list of frames with such style contexts), but I think that's probably sufficient for a first pass. (This takes care of inheritance, and also takes care of any descendants that independently use v* units.) * if the list is non-empty, then when the viewport height or width changes, we walk the frame tree looking for frames with such root-most style contexts with the bit, and we reresolve their subtrees.
* any style context with v* units gets a bit set on it, and if it's the root-most style context with the bit, gets put in a list of such style contexts on the style set (and removed from that list when destroyed) * (not necessary, but makes things a lot simpler) anything with v* units gets canStoreInRuleTree = false * v* units get computed in the CalcLengthWith function in nsRuleNode.cpp I think it will be simpler to implement them in the style system. The first question is whether to implement these in the style system (like 'em' units) or in layout (like '%'). But in case you are interested, but are just blocked on getting started and figuring out what to fix, we could help you with that - just say the word. Of course, if you're not interested, that's fine too - everyone has their thing. I'm willing to do that, to the extent that I can (part of the appeal of doing this myself would be that it's a little bit of a stretch, so I'd probably point you at others assuming you met questions I couldn't answer at some point), if you're interested.
When you say "If I had the foggiest idea how I would contribute support myself": are you saying you have no idea because you don't know the code, because you don't know C++, because you don't program, because you've never worked with Mozilla code before, because you're solely an interested observer, or what? If you know C++ but don't know Gecko, someone could help you get started and probably point you at the relevant code that would need touching.
But I have other projects I've lightly committed myself to first ( bug 483446 for one), so this would be back-burner of back-burner for me at best. I've thought about attempting to pick this up myself, as a way to learn more about the layout engine (in which I have lightly dabbled, mostly with painting-only changes, nothing affecting dimensions or positioning yet). I'm not aware that anyone is, although I'm not the most informed person on layout happenings these days. > (Percentages are different since they're relative to the parent or > for handling dynamic changes (to the size of the viewport). > What you're missing is that vh, vw, and vm require a new mechanism On www-style, David Baron mentions an additional complication: Bug 472195 (adding rem element) might be useful for reference.
These would be extremely useful for authors - quite a few very nasty hacks could be retired if we could use these (like and ).Īs far as I know, no other rendering engine implements any of these units yet. These are respectively proportional to the width of the viewport, the height of the viewport, and the minimum of the two. User-Agent: Mozilla/5.0 (X11 U Linux i686 en-US) AppleWebKit/531.3 (KHTML, like Gecko) Chrome/3.0.193.0 Safari/531.3ĬSS 3 Values and Units specifies vw, vh, and vm units.