* Using .connect(", ") just to use .split(",") later is silly. Keep it a vector.
* The 'font-style' property can not be both italic and oblique. Use an enum instead of two booleans.
Local bookmark which is implemented in #1262 is not currently working when executing URL with hashtag(e.g. `test_local_bookmark.html#h3`, `acid2.html#top`).
Local bookmark has two matching processes(http://www.w3.org/TR/html5/browsers.html#scroll-to-fragid). Among two, this commit fixes the crash on ID attribute, and still has crash on `a` element with `name` attribute.
As a result, with this commit, `test_local_bookmark.html#h3` works well, but `acid2.html#top` still does not work.
1. We've aimed to android 4.3 Jellybean devices like Galaxy 10.1 and Galaxy Nexus, etc. I think it could still support android 4.1
2. Needs android ndk r9(not r9b) and latest android sdk
3. Needs some device list update on sdk for apk build.
4. Currently we can not build android port on mac because compiler build problem like https://github.com/mozilla/rust/pull/10921. Hopefully I expect that it could be resolved at next rust upgrade.
* Using .connect(", ") just to use .split(",") later is silly.
Keep it a vector.
* The 'font-style' property can not be both italic and oblique.
Use an enum instead of two booleans.
Implement Document's 'body' attribute (getter and setter). Proper
implementation of setter requires Node::ReplaceChild(), which is
currently a stub and will be done on a later step.
This patch is for:
https://github.com/mozilla/servo/issues/1428
Implement Document's 'body' attribute (getter and setter). Proper
implementation of setter requires Node::ReplaceChild(), which is
currently a stub and will be done on a later step.
This patch is for:
https://github.com/mozilla/servo/issues/1428
This changeset gets rid of the `FooView` phantom type in favor of a more brute force approach that just whitelists methods that layout is allowed to call. The set is surprisingly small now that layout isn't going to the DOM for much.
If this approach turns out not to scale, we can do something fancier, but I'd rather just have it be safe and secure first and then refactor later for programmer happiness.
r? @kmcallister
