--- layout: post title: Prototype Element Update Confusion date: 2009-08-05 23:49:14.000000000 +01:00 categories: - eprints - javascript tags: - javascript - prototype status: publish type: post published: true meta: _edit_last: '4005008' author: Marcus Ramsden ---
At work we are currently working on reimplementing a piece of software called SNEEP. SNEEP is a plugin for repository software called EPrints which is developed at the University of Southampton. According to the Registry of Open Access Repositories (ROAR) EPrints currently has 333 installations around the world as of 6th August 2009. As part of the SNEEP plugin we have been adding in the ability to edit comments and notes using AJAX meaning that users don’t have to leave the deposit page to author their comments or notes.
EPrints comes with the Prototype and Scriptaculous JavaScript libraries installed so we had to use these as opposed to my regular choice of jQuery. Owing to the static approach used for generating the document views in EPrints we had to inject the whole comments section of the document using AJAX. We did this by having the server generate the DOM and then sending it back to the browser which injects it into the page. This way the page can dynamically load the comments box depending on if a user is logged in or not.
Initially we managed to get the code running with Firefox and Safari but we had no joy with the code in IE. Here is some of the code that was originally used.
{% highlight javascript linenos %} function sneepCommentFormInit(transport) { // Load in the HTML generated by the server side script $('ep_sneep_main').update(transport.responseText); // If the server sent back a form so the user can write a new comment // then we need to remove the old submit button and add one which is // attached to one of our JavaScript functions. $$('.ep_sneep_comment_form_container').each(function(element) { var submitButton = document.createElement('input'); submitButton.writeAttribute('type', 'button'); submitButton.writeAttribute('id', 'sneep_comment_submit'); submitButton.writeAttribute('value', $('sneep_comment_submit').readAttribute('value')); submitButton.observe('click', sneepCommentFormSubmit); $('sneep_comment_submit').remove(); element.appendChild(submitButton); var inputcallback = document.createElement('input'); inputcallback.writeAttribute('type', 'hidden'); inputcallback.writeAttribute('name', 'callback'); inputcallback.writeAttribute('value', '1'); element.appendChild(inputcallback); }); } Event.observe(window, 'load', function() { var rm = window.location.href.match(/(https?:\/\/.*)\/(\d+)\/?/); if (rm != null) { new Ajax.Request(rm[1]+'/cgi/sneep/view_sneep?eprintid='+rm[2]+'&type=comment', { method: 'get', onCreate: function() { // Put up a loading message }, onComplete: sneepCommentFormInit }); } }); {% endhighlight %}The problem appeared to be that IE does not finish loading the updated content before attempting to add the hidden field and attaching a new submit button which calls our client side method rather than allowing the form to submit straight back to the server.
The solution we chose for this issue was to modify the initial on load function in the following way;
{% highlight javascript linenos %} Event.observe(window, 'load', function() { var rm = window.location.href.match(/(https?:\/\/.*)\/(\d+)\/?/); if (rm != null) { new Ajax.Request(rm[1]+'/cgi/sneep/view_sneep?eprintid='+rm[2]+'&type=comment', { method: 'get', onCreate: function() { // Put up a loading message }, onComplete: function(transport) { $('ep_sneep_main').update(transport.responseText+ ''); } }); } }); {% endhighlight %}Basically in this code we removed the code from sneepCommentFormInit() that handles the returned text and put it inside the anonymous onComplete method. We also appended some JavaScript that gets executed as soon as it is evaluated. This means that the form initialization code is only run once all of the HTML has been interpreted and loaded meaning that IE now has the submit intercept function correctly attached.


This project aims at drawing nice pictures with nested polygons forming cool spirals. Nothing more, nothing less. For SVG sxport, go check here!

In edition mode, click on the canvas to place or remove a point, click and drag between two points to draw polygon segments, and finally click "Draw!" to trace spirals.


Preparation time
30 mins to 1 hour
Cooking time
30 mins to 1 hour
Serves
Serves 2-4
Dietary
Firstly make the sweet onion marmalade. Heat the oil in a pan, add the onions and fry for 1 minute. Add the sugar and caramelise lightly together.
Pour over the vinegar and red wine, add the thyme and leave to cook over a gentle heat until reduced and has a jam consistency - about 25 minutes (this can be made well in advance). Chill until ready for use.
Lay out the pastry sheets and brush liberally all over with eggwash. Place a spoonful of onion marmalade in centre of each sheet, then top with goats cheese. Wrap up securely to enclose the cheese within using eggwash as glue.
Heat the vegetable oil in a large pan to 170C/325F - you could bake them in the oven too if you wanted.
Meanwhile for the salad, place all three salad leaves in a bowl. Top with the avocado, fresh pear and celery and season lightly.
Make a dressing from the mustard, honey, balsamic vinegar, oil, salt and pepper. Pour over the salad, add the walnuts and dress on a serving plate (either individual or one large serving plate).
Fry the goats' cheese parcels for 1-2 minutes until golden and crispy, remove and drain on kitchen paper and dress on the salad. Serve immediately.


This is a basic search with a client side source.
This is a search that uses the search callback to filter out the results.
Searching also allows for categories to be built out.
A set of directives and components that work together to create a search component.
| Usage | Description | |
|---|---|---|
| .ui.search |

 | The container for the component of the search. *Note the results div is not needed because it is added by this component. |
| input.prompt | <input type="search" class="prompt" /> | The search input that will be used for this search component. |
Settings that can be added to the elements to change the functionality of the search component.
| Default | Description | |
|---|---|---|
| [transition] | fade | The animation transition that should be used when this element is displayed and hidden. |
| [duration] | 200 | The duration of the transition. |
| [source] | The local search object to be used for searching. | |
| [maxResults] | 7 | The number of max results that should be displayed when the search is done. |
| [searchCallback] | The search callback that should be called instead of the internal callback. | |
| [debounce] | 400 | The number of milliseconds that should be delayed before searching will take place. |


GuardianVets
A 3-week UX design sprint for GuardianVets, a veterinary telehealth startup based in Evanston
Team: 3-person UX team
Skills: UX design and strategy, interaction design, service design
Tools: Sketch, Axure
Working with GuardianVets was a new experience on a few dimensions. I had never worked with a startup, nor had I worked on a B2B product. As an added bonus, I looked forward to working with fellow animal lovers and learning more about a space that impacts my life as a dog owner.
PROJECT OVERVIEW
GuardianVets is a B2B veterinary telehealth startup that provides off-hours teletriage support to the clients of veterinary clinics. As founder and CEO John Dillon stated, “We take over the phones when a practice is closed and our team of DVMs and CVTs help clients understand whether their pet’s concerns are emergent.” The company developed an internal-facing system largely utilizing 3rd party software, launched in February 2017. The system allows the GuardianVets staff to take calls, collect pertinent details, and submit the information to the referring vet clinic via email.
Now having more than 50 clinic clients, GuardianVets was outgrowing their current proof-of-concept system. They asked our team to develop a tool to facilitate scaling by improving call efficiency, data quality, and reporting capabilities. In our initial conversation, the client suggested his top priority was to develop the clinic-facing segment of the system. He also indicated that the GuardianVets team and management-facing portions of the system were a high priority, as well.
Who we designed for
As we dove into our research, we had a handful of things we wanted to learn:
- The distinction between telemedicine services and teletriage
- Gaps in the triage or pet telehealth market
- The current GuardianVets experience for clinics and the internal team
- What information is most important to vet clinics
- What clinics and pet owners value most about the GuardianVets service
- Current product pain points
Identifying a few key points of focus, this frame felt like a good start. Of course, we knew we had to keep an eye out for emergent questions and themes as we gained an understanding of the challenges and business context in which GuardianVets operates. Since our team didn’t have previous knowledge of pet telehealth, our research started with an examination of the domain and competitive landscape.
DOMAIN RESEARCH
Foundational to all veterinary care is the concept of a veterinarian-client-patient relationship (VCPR). A VCPR is present when it meets the following requirements:
- The vet has assumed responsibility for making clinical judgments; the client has agreed to follow instructions.
- The vet has enough knowledge of the patient to make a preliminary diagnosis.
- The vet is available for follow-up.
- The vet provides oversight of treatment, compliance, and outcome.
- The vet maintains patient records. Exception: a veterinarian can give advice in an emergency situation.
Pet telehealth has two main segments:
- Telemedicine, which is client-facing, includes the delivery of information specific to a particular patient and is allowable only within the context of an established VCPR. An example of telemedicine is a veterinarian observing a pet under their care via video chat.
- Teletriage (or tele-advice) is a non-client-facing model that involves delivery of general advice, health information, or recommendation for future actions. This advice that is not intended to diagnose or treat, but to help make an assessment available options (i.e. whether a situation requires a trip to the ER or not).
Since GuardianVets doesn’t establish a VCPR with callers, the service falls into the teletriage space, meaning that the staff must stay clear of diagnosing, prognosing or treating patients. Any advice given should remain in general terms, not specific to an individual animal, diagnosis or treatment. Oriented within the world of pet telehealth, I next looked into competition in the market space.
My analysis showed that GuardianVets was the only competitor offering 24-hour support to clinics. To that end, GuardianVets was also the only competitor offering phone-based after-hours support to vets. The only other competitor offering after-hours support, Ask.vet, did so via a text-based platform. Our client suspected that GuardianVets was the lone competitor in this particular niche, and my analysis supported that suspicion, leading us to believe that they were well-positioned within the pet telehealth space as a high-touch service.
USER INTERVIEWS
With a better understanding of the competitive landscape, it was time to talk to some users. We spoke to nine and wanted to find out how the various stakeholders connected to each other through the product and service, as well as to understand what did or didn’t currently work.
WHAT WE HEARD FROM CLIENTS
Our interviews confirmed much of what our client had suggested—the vet clinics wanted more and better data to support operations and to better gauge the value of GuardianVets. They especially wanted a firmer grasp of the revenue generated by referred appointment and new clients. We found that when clients described what they valued most about the service, they all primarily focused on the customer service aspect—it gives the pet owners and veterinarians peace of mind off-hours. The clients often described pet owners as wanting another person to talk to as a sounding board during a difficult time. Since the marketing also focuses heavily on ROI, we found that the clinics measured the value of the service in terms of revenue.
Client Insights
“They're not out there alone, they have GuardianVets listening to them.”
-Cathy GuardianVets client and clinic administrator
“I wish there had been more of a breakdown to see how many were recommended to go to the ER and how many came to us for follow up appointments.”
-Robin, GuardianVets client and clinic administrator
“We know that we’re not getting the ROI we want... but it’s harder to quantify the value in terms of customer service and screening… The data isn’t obvious enough to make a compelling case.”
-Ben, GuardianVets client and clinic owner
WHAT WE HEARD FROM THE TEAM
The GuardianVets team appreciated the ability to work remotely in the veterinary field, and they were all invested in helping pet owners and providing excellent customer service. They echoed the clinics in suggesting that pet owners valued the person-to-person connection at what was often a stressful time.
The team highlighted issues with the current internal-facing platform that led to frustration, wasted time, and diminished data quality and detail. Most notably team members mention forms disappearing in the system when a new call comes in. If a form disappears, they have to call the referring hospital and go through the GuardianVets menu to trigger a new one. Also, after losing so many partially-completed forms, team members began handwriting notes and entering fewer details.
GuardianVets Team Insights
“Up until last September I worked in a private practice, but I had to quit due to heart issues. I stumbled upon GuardianVets… and I could work at home which was just wonderful.”
-Cathy, GuardianVets team member
“If I’m lucky I’ll fill out the form with a client, finish the call and hit submit, I just haven’t been doing this because I’m afraid some else will call and the form will disappear.”
-Jen, GuardianVets team member
“If I’m working on a form and a new call comes in, the new call supersedes the form and the form disappears. So I handwrite instead of using the form because it will usually disappear. Last night it took me four tries to get a form done.”
-Melodie, GuardianVets team member
DEFINING THE PROBLEM AND THE SCOPE
As the week unfolded and themes and insights began to emerge, our team decided that given the short project length, we needed to focus on either the clinic-facing or staff-facing experience. Our client had prioritized the clinic-facing part of the system, and at that time we thought that would be a more interesting challenge. As we conducted our interviews and learned more, we decided that the staff-facing part of the system presented a more critical, foundational, and actionable problem to solve. We created a problem statement to articulate the problem as we had come to understand it:
GuardianVets staff needs an efficient, but non-restrictive platform for consistent data entry which includes in-call access to client information, so calls can be completed immediately and accurately, leading to improved data quality and fostering continued growth.
To further help guide our design decisions, the team came up with four guidelines to focus our design decisions moving forward.
Given that GuardianVets’ immediate concern was scaling their operation, improvements to the efficiency of the internal call system would increase capacity without having to add staff. It also benefited clinics by enabling more timely and detailed call reports. Management benefited from a much more efficient centralized review process, a task currently handled by one person. We had to make sure our solution prioritized critical information, featured efficient forms that were persistent and easy to learn, and promoted naturalistic interactions between pet owners and the GuardianVets team.
We presented our findings and proposed scope to our client in our next meeting. Knowing that he had prioritized a different part of the site, we prepared to make our case. As expected, the client felt hesitant about the shift in focus, but as the discussion continued, he ultimately suggested that our conversation had caused him to consider his business from a new perspective. Aligned with our client on the focus of the problem, we moved on to generating ideas for solutions.
POTENTIAL SOLUTIONS
With our problem, design guidelines, and insight in mind, we brainstormed ideas on what needed be the critical elements of the system for us to test. As a team, we identified these areas of focus:
- Reformatting and streamlining the existing form
- Persistent forms with pre-populated info (e.g., vet practice name, caller ID)
- Presenting relevant clinic details in a form (e.g., on-call schedule, hours)
- In-system review of completed forms
- Taking calls on the cell vs the computer
Concept 1: Streamlined Input Form
Design considerations: form layout, input efficiency, learnability, form content
We heard the intake form had significant structural flaws which slowed down the staff when they filled out a form and led to a tremendous amount of frustration and wasted time. I evaluated the existing form and built an updated version directly in Axure, adjusting layout and inputs to increase efficiency and learnability. Specifically, I focused on breaking the form into digestible sections, labelling inputs clearly, and eliminating dropdowns in favor of radio buttons and predictive searches. I left the content of the form largely intact, making only a few small tweaks. We wanted to get a clearer sense of user pain points as they interacted with the form while on a call, as well as their reactions to the initial structural changes to the form.
Concept 2: Desktop to Mobile
Design considerations: dashboard view, call waiting, vet clinic info, mobile view
The Desktop to Mobile concept explored user dashboards, displaying clinic information in the context of an intake form, as well as a mobile interface. We wanted to know if a dashboard view would be desirable for the users, and if so, what information would be most useful. We also wanted to determine whether the clinic information being shown in context with the form clearly displayed the necessary information. Finally, we wanted to hear users’ thoughts on developing a mobile platform for handling calls.
Concept 3: Finalize Form
Design considerations: pre-populated information, notifications, persistent forms, in-application reviews
The Finalize Form concept explored the idea of a staff member opening an in-process form, completing it, and submitting it. The concept also introduces an in-application review process. We wanted to know if the users understood the workflow and found the in-system review functionality desirable.
CONCEPTS TO PROTOTYPE
After discussing the results of the concept testing with our client, the team felt the best direction forward involved combining aspects of each prototype, prioritizing the features that were essential to ensuring efficient call handling.
To handle calls and complete forms efficiently, our prototype featured a clear and actionable home screen, streamlined decision support form, and call queue that is always visible. We included an in-system case review and a history of closed calls to provide transparency and ease administrative burden. We also wanted to continue to explore the concept of a user-focused analytics dashboard as a means to both inform the staff of their own performance and provide management a way to communicate key performance metrics.
-
Active Cases Tab
-
Decision Support Form
-
In Review Tab
-
Review Form
-
Closed Calls Tab
-
Analytics Tab
USABILITY TESTING
After we built the key screens, I unified them into a working prototype. It was now time to test the usability of the prototype with the GuardianVets team. Unfortunately, two of the three users had to cancel, so we also asked the team manager to test the design. This wasn’t ideal, but we gathered some great insights, and we were glad to get the team manager’s perspective, as well.
We heard that the users found the layout and navigation to be intuitive, and the high-level tabs were clear and easy to understand. They understood and desired the functionality, especially the ease of data entry, the ability to return to a form, and the in-system review process.
We also found some areas that needed refinement. Some in-page labelling was unclear, and any metrics referring to a time frame needed to be more specific. For example, it was unclear if “calls last week” meant calls from the last calendar week or the last 7 days.
We also uncovered a significant usability issue that we addressed immediately. In our initial design, the decision support form obscured the dial-out button, but we found that users dialed out most often when they were actually already on a call and needed to contact a vet. As a result, we did a quick redesign of the top of the page, moving the call button to the right column where it would remain visible and active when a user had a form open.
FINAL DESIGN
After making the handful of changes resulting from usability testing, we put together annotated wireframes so our client could move the project forward with a UI or development team. At the final meeting with our client, we presented our prototype, testing results, final designs, and future considerations. He loved what he saw:
“In 3 weeks… not only did they uncover a problem I didn’t see, they re-engineered a core process in a way that will drive a lot of value for us in the future, came up with a design that is intuitive for my team members to use and frankly looks a lot cooler.”
Final Prototype Screens
Annotations
FUTURE CONSIDERATIONS
Given the three-week design sprint, we couldn’t address everything. I put together an inventory of what we thought should come next.
Testing: Given the limited amount of testing we were able to do, we recommend more to validate usability as the system develops.
Unique IDs: Given the limitations of using a telephone number as a unique identifier, we wanted GuardianVets to consider developing an ID system that can reconcile callers using multiple numbers, having multiple pets, or pets having multiple owners.
The form: When building the client-facing section of the system, ensure that the clinics will be able to update their own clinic information. This will be critical as the business scales.
Messaging: Enable the GuardianVets team to communicate within the platform to lessen their reliance on personal devices and accounts, centralize communication records for reference, and allow an opportunity to indicate user status (e.g. online, on a call, on break, offline, etc.)
Protocol: As a more formal triage protocol develops, strive to maintain the balance between building a standardized process and maintaining the highly valued aspect of a person-to-person interaction.
The list of considerations laid out a path to improve the experience for all users through increased analytical flexibility, efficient customization, centralized communication, and a service structure that embraces a core value proposition of the service: human interaction. Nailing this benefits all stakeholders—pet owners, vet clinics, the GuardianVets team, and the business as a whole.
CONCLUSIONS / LESSONS LEARNED
New territory
This was also my first time working on a B2B product. It was a challenge to consider and reconcile the needs and goals of the multiple involved parties: GuardianVets management and staff, vet clinics, and pet owners.
From the jump
In retrospect, we were not completely aligned with our client at the outset around expectations for setting up user interviews, access to the current platform, and the design process in general. Had we firmly established these expectations at the outset, we likely would have saved some scrambling throughout the project.
Make your case
This was my first experience challenging a client’s stated preferences and point of view. Even if it led to a few uncomfortable moments, it was the right decision to advocate for the user and for what our research suggested was best for all stakeholders and for the business as a whole.
Focus on foundation
In defining and scoping our problem, we focused on one we thought would benefit all users—this rationale really resonated with our client. I’ll definitely make it a point to look to focus on core issues that pay system-level dividends.
Having the opportunity to step into users’ ultra-familiar day-to-day experiences was both fascinating and rewarding. It’s fulfilling to think that improvements you can make on a system will pay direct and significant dividends to the people we met. This is exactly the kind of thing that draws me to design and excites me to continue to find opportunities to practice in the future.


{# adapted from https://docs.djangoproject.com/en/3.2/topics/pagination/ #} {% load minifilter_extras %}


|
|
Container_bptreeIntroduction |
1. Is it possible to sum up any N consecutive numbers in less than N-1 operations?
Yes, it is possible, but it is not completely trivial. The best possible efficiency of an algorithm is often limited by the complexity of a data structure. For example, both a linked list and a tree can represent a sequence, but out of these two data structures only a tree can support a search algorithm with logarithmic running time.
In the current version of the namespace container_bptree
, one
variant of a B+ tree supports an algorithm, which sums up any N
consecutive numbers in O(log N) operations in the worst case.
2. Why is it important?
The addition is a fundamental operation in the modern computational world. This operation passes through every level of practical use of computers from single bits to large scale applications, such as databases or models of financial markets. Many applications deal with huge and constantly growing volumes of data and thus require the increasing computational power of systems.
An algorithm, which sums up 1,000,000,000 elements in only 100 operations, is astronomically more cost effective against an equivalent hardware upgrade. It can help improve efficiency and quality of data analysis, problem solving and business modeling.
Advanced data structures offer advanced facilities for data processing and analysis. The B+ trees implemented in this project represent the class of advanced data structures. In addition to super fast summation, these trees provide several other useful extensions of STL containers and iterators.
Revised 27 November, 2011
Copyright © 2011
Vadim Stadnik
<EMAIL_ADDRESS>Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)


EPUB
EPUB is the distribution and interchange format standard for digital publications and documents based on Web Standards. EPUB defines a means of representing, packaging and encoding structured and semantically enhanced Web content — including XHTML, CSS, SVG, images, and other resources — for distribution in a single-file format.
Geo-F/X's principal, Ric Wright, is one of the original members of the IDPF EPUB working group. He has played an instrumental role in creating both the EPUB 2 and EPUB 3 specifications, He continues this role today as the WG continues with the EDUPUB profile and EPUB 3.1.
While at Adobe, he championed the nascent EPUB specification and led the team that created the first implementation of an EPUB Reading System in Adobe Digitial Editions and the Sony Reader PS-500.


Publications most similar to methods based on abstracts
How similar are your publications to a large set based on the context? I first derived a vector representation for each of the methods in the large set using a method called word2vec. I could then parse the text from each of your publication abstracts, and map it to this space by taking a mean vector for all the words I find in your abstract. I can then calculate a similarity score of this vector to all the method vectors individually. What you are looking at is a list of top matches (scores > 0) that are matched to {{ themethod }}
Where are all the visualizations?
They are coming soon! This view was put together in a weekend afternoon, and you can expect the tool to be updated with views for methods, and interactive graphs across authors. For now, you can look at collaborations between authors based on a set of papers, or explore the data and code more fully on github.


Bottom Sheets are like panels. But instead of coming from the left or the right they appear from the bottom.
Two different typesA bottom Sheet can be presented as a list (items are displayed in rows) or as blocks (items are displayed in floated square-blocks)


Although my maven bitching has been mostly snarky, I have come to truly believe it is the wrong tool for a growing enterprise and, like centralized version control, will lead to a situation where tools dictate process (and design).
But, what is maven actually good at?
- Maven is great for getting started – you don’t have author an ant file (or copy one from an existing project)
- Maven is great for enforcing a standard project structure – if you always use maven, your projects always look the same
Dependency management is not a build step
Maven is the equivalent of doing a sudo gem update everytime you call rake, or doing a sudo yum update before running make. That’s just insane. While automated dependency management is a key feature of a sophisticated development process, this is a separate process from developing my application.
Maven’s configuration is incredibly verbose
It requires 36 lines of human-readable XML to have my webapp run during integration tests. Thirty Six! It requires six lines just to state a dependency. Examining a maven file and tying to figure out where you are in its insane hierarchy is quite difficult. It’s been pretty well-established outside the Java community that XML is horrible configuration file format; formats like YAML have a higher signal to noise ration, and using (gasp) actual scripting language code can be even more compact (and readable and maintainable).
The jars you use are at the mercy of Maven
If you want to use a third-party library, and maven doesn’t provide it (or doesn’t provide the version you need), you have to set up your own maven repo. You then have to include that repo in your pom file, or in every single developer’s local maven settings. If you secure your repo? More XML configuration (and, until the most recent version, you had to have your password in cleartext…in a version 2 application). The fallout here is that you will tend to stick with the versions available publicly, and we see how well that worked out for Debian.
Modifying default behavior is very difficult
Since maven is essentially a very, very high-level abstraction, you are the mercy of the plugin developers as to what you can do. For example, it is not possible to run your integration tests through Cobertura. The plugin developers didn’t provide this and there’s no way to do it without some major hacking of your test code organization and pom file. This is bending your process to fit a tool’s shortcoming. This is limitation designed into maven. This is fundamentally different that “opinionated software” like Rails; Rails doesn’t punish you so harshly for wanting to tweak things; maven makes it very difficult (or impossible). There was no thought given in Maven’s design to using non-default behavior.
Extending Maven requires learning a plugin API
While you can throw in random Ant code into maven, the only way to create re-usable functionality is to learn a complex plugin API. Granted, this isn’t complex like J2EE is complex, but for scripting a build, it’s rather ludicrous.
Maven is hard to understand
I would be willing to bet that every one of my gripes is addressed through some crazy incantation. But that’s not good enough. The combined experience of the 7 developers at my company is about 70 years and not one of us can explain maven’s phases, identify the available targets, or successfully add new functionality for a pom without at least an hour on the net and maven’s documentation.
A great example is the release plugin. All five developers here that have used it go through the same cycle of having no idea what it’s doing, having it fail with a baffling error message, starting over and finally figuring out the one environment tweak that makes it work. At the end of this journey each one (myself included) has realized all this is a HUGE wrapper around scp and a few svn commands. Running two commands to do a source code tag and artifact copy shouldn’t be this difficult.
 While maven’s description of itself is a complete fabrication, it at least has its heart in the right place. However, it STILL fails to solve make’s shortcomings wrt to java:
- Maven doesn’t recompile the java classes that are truly out-of-date
- Maven recompiles java classes that are not out-of-date
- Maven doesn’t allow for sophisiticated behavior through scripting
- Maven replaces arcane magic symbols with arcane magic nested XML (e.g. pom files aren’t more readable than a Makefile)
Maven is slow
My test/debug cycle is around a minute. It should be 5 seconds (and it shouldn’t require an IDE).Conclusion
Apache’s Ivy + Ant is probably a better environment than maven for getting things done; a bit of up-front work is required, but it’s not an ongoing cost, and maintenance is much simpler and more straightforward. Tools like Buildr and Raven seem promising, but it might be like discussing the best braking system for a horse-drawn carriage; utterly futile and irrelevant.


Loads an ajax driven page and generates the html for google to crawl. Check out the tutorial
for a more complete walkthrough.
This crawler indexes an entire Ajax site. It
Opens a page in a headless browser.
Waits until its content is ready.
Scrapes its contents.
Writes the contents to a file.
Adds any links in the page that start with #! to be indexed
Changes window.location.hash to the next index-able page
Goto #2 and repeats until all pages have been loaded
2. Wait until content is ready.
By default, steal.html will just wait until all scripts have finished loading
before scraping the page's contents. To delay this, use
[steal.html.delay] and steal.html.ready.
3. Write the contents to a file.
You can change where the contents of the file are writen to by changing
the second parameter passed to crawl.
By default uses EnvJS, but you can use PhantomJS for more advanced pages:
Loads an ajax driven page and generates the html for google to crawl. Check out the tutorial for a more complete walkthrough.
This crawler indexes an entire Ajax site. It
window.location.hash
to the next index-able page2. Wait until content is ready.
By default, steal.html will just wait until all scripts have finished loading before scraping the page's contents. To delay this, use [steal.html.delay] and steal.html.ready.
3. Write the contents to a file.
You can change where the contents of the file are writen to by changing the second parameter passed to
crawl
.By default uses EnvJS, but you can use PhantomJS for more advanced pages:


--- layout: archive title: Zulip Chat Archive permalink: /stream/113489-new-members/topic/leanpkg.20args.html ---
Hi,
Is it possible to
(a) make leanpkg build
stop at the first error like the normal make
does?
(b) get per-file build time stats?
(c) same, but per-def/lemma in a file?
I want (a) when I change some defs, and want to fix all newly broken files one by one, and (b)/(c) to know I should look at if I want to speed up the compilation process.
For a), look at scripts/detect_errors.py
in mathlib, we had to hack it together for the travis build
For b) and c), have you looked at lean --profile
?
(or leanpkg -- --profile
)
@Simon Hudon Thank you
{% endraw %}Last updated: Apr 24 2020 at 19:02 UTC


Thanks for your interest, our staff of talented educators will be in touch with you shortly!
Our vTutor instructors are experienced certified educators who provide the highest quality of effective instruction for all students. They are well versed in the delivery of common core standards and effective instructional practices. Our instructors are compassionate, enthusiastic and caring and understand how to build a positive rapport with students and parents.
The vTutor educator is trained to set and create an environment of high expectations to ensure the highest quality of teaching and learning while engaging and empowering the students to reach the highest level of achievement. The enrichment opportunities provided by vTutor educators are unlimited by focusing on the individual needs of each student.


Loops
Problem 1. Numbers
Write a script that prints all the numbers from 1 to N.
Number:
Go
Clear Console


Loading...
Note:
This was last updated with cards from the Descent of Dragons expansion.
Include wild cards
Include wild cards
Back
Reroll
Craft another
Randomize
Download
Back


Helping one person at a time
Type: {{story.type}}
{{story.desc}}
Posted by {{story.author}} on {{story.showDate}}


Enter a command to pass to the SERVERNAMEFEILD and press send to deliver.
When commands are sent, their status is shown here.
For more info see the Github Repository for this project or view the README.md for this tool.
©Copyright, QLab, Queen's University Belfast, 2019


- A Message from Warren E. Buffet
- Annual and Interim Reports
Updated August 7, 2015
- Special Letters From Warren & Charlie RE:Past, Present, and Future
- Link to SEC Filings
- Links to Berkshire Subsidiary Companies
- Corporate Governance
- Owner's Manual
- Letters from Warren E. Buffett Regarding Pledges to Make Gifts of Berkshire Stock
- News Releases
Updated August 10, 2015
- Warren Buffett's Letters to Berkshire Shareholders
Updated February 28, 2015
- Charlie Munger's Letters to Wesco Shareholders
- Annual Meeting Information
- Celebrating 50 Years of a Profitable Partnership
(A commemorative book first sold at the 2015 Annual Meeting and now for sale on eBay.)
- Comparative Rights and Relative Prices of Class A and B Stock
- Berkshire Activewear
FOR A FREE CAR INSURANCE RATE QUOTE THAT COULD SAVE YOU SUBSTANTIAL MONEY WWW.GEICO.COMOR CALL 1-888-395-6349, 24 HOURS A DAY


--- layout: post title: HTML Programming with Visual Studio Code date: '2019-09-25T12:43:00.000+05:30' author: Sahil Rajput tags: modified_time: '2019-09-25T12:44:01.687+05:30' blogger_id: tag:blogger.com,1999:blog-5250005448924290719.post-6719866075052394000 blogger_orig_url: https://www.jaadujinn.ml/2019/09/html-programming-with-visual-studio-code.html ---


My oudjo
Library
Search results
Settings
About
oudjo
Songs
Artists
Albums
Genres
Playlists
My oudjo
Songs
Artists
Albums
Genres
Playlists
Settings
Search results for {{search-bar-query}}
Songs
Artists
Albums
About
{{player-song-title}}
{{player-song-info}}


Copyright © 2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
The APIs introduced by this specification provide authors with a way to inspect and manipulate the visual view of a document. This includes getting the position of element layout boxes, obtaining the width of the viewport through script, and also scrolling an element.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the 15 October 2014 Editor's Draft of CSSOM View. Please send comments to<EMAIL_ADDRESS>(archived) with [cssom-view] at the start of the subject line.
This document was produced by the CSS Working Group (part of the Style Activity).
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Window
Interface
Document
Interface
Element
Interface
HTMLElement
InterfaceHTMLImageElement
InterfaceRange
InterfaceMouseEvent
InterfaceMany of the features defined in this specification have been supported by browsers for a long period of time. The goal of this specification is to define these features in such a way that they can be implemented by all browsers in an interoperable manner. The specification also defines a couple of new features that will hopefully be useful to authors. (If they are not you can bug us!)
All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119]
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and terminate these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)
User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.
When a method or an attribute is said to call another method or attribute, the user agent must invoke its internal API for that attribute or method so that e.g. the author can't change the behavior by overriding attributes or methods with custom properties or functions in ECMAScript.
Unless otherwise stated, string comparisons are done in a case-sensitive manner.
A conforming user agent implements all the requirements made by this specification.
The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [WEBIDL]
Terminology used in this specification is from DOM, CSSOM and HTML. [DOM] [CSSOM] [HTML]
MouseEvent
and MouseEventInit
are defined in …
DOMPoint
,
DOMPointReadOnly
,
DOMPointInit
,
DOMRect
,
DOMRectReadOnly
,
DOMRectList
and
DOMQuad
are defined in Geometry Interfaces Module. [GEOMETRY]
The HTML body
element is the first
body
HTML element child of the root
HTML element html
.
Content edge, padding edge, border edge, margin edge and canvas are defined by CSS.
Viewport and initial containing block are defined by CSS 2.1.
Block flow direction and inline base direction are defined in CSS Writing Modes Module. [CSSWRITINGMODES]
Converted to an IDL value is defined in Web IDL. [WEBIDL]
Elements and viewports have an associated scrolling box if has a scrolling mechanism or it overflows its content area and the used value of the 'overflow-x' or 'overflow-y' property is 'hidden'. [CSSBOX]
A scrolling box of a viewport or element has two overflow directions, depending on the viewport's or element's block flow direction and inline base direction, as follows:
Rightward and downward.
Leftward and downward.
Leftward and upward.
Righward and upward.
The term scrolling area refers to a box of a viewport or an element that has the following edges, depending on the viewport's or element's scrolling box's overflow directions.
| If the overflow directions are… | For a viewport | For an element |
|---|---|---|
| rightward and downward |
|
|
| leftward and downward |
|
|
| leftward and upward |
|
|
| rightward and upward |
|
|
The origin of a scrolling area is the origin of the initial containing block if the scrolling area is a viewport, and otherwise the top left padding edge of the element when the element has its default scroll position. The x-coordinate increases rightwards, and the y-coordinate increases downwards.
The beginning edges of a particular set of edges of a box or element are the following edges:
The top and left edges.
The top and right edges.
The bottom and right edges.
The bottom and left edges.
The ending edges of a particular set of edges of a box or element are the following edges:
The bottom and right edges.
The bottom and left edges.
The top and left edges.
The top and right edges.
The term CSS layout box refers to the same term in CSS. For the purpose of the requirements in this specification, elements that have a computed value of the 'display' property that is 'table-column' or 'table-column-group' must be considered to have an associated CSS layout box (the column or column group, respectively).
The term SVG layout box refers to the same term in SVG.
The terms CSS layout box and SVG layout box are not currently defined by CSS or SVG.
The term layout box refers to either a CSS layout box or an SVG layout box.
The term transforms refers to SVG transforms and CSS transforms. [SVG] [CSSTRANSFORMS]
All coordinates and dimensions for the APIs defined in this specification are in CSS pixels, unless otherwise specified.
This does not apply to e.g.
matchMedia()
as the units
are explicitly given there.
There are two kinds of zoom, page zoom which affects the size of the initial viewport, and pinch zoom which acts like a magnifying glass and does not affect the initial viewport or actual viewport. [CSSDEVICEADAPT]
When a user agent is to perform a scroll of a scrolling box box, to a given position position, with a set of
steps task, an associated element element and optionally a scroll behavior behavior (which is
auto
if omitted), the following steps must be run:
Abort any ongoing smooth scroll for box.
If the user agent honors the 'scroll-behavior' property and one of the following are true:
behavior is auto
and element is not null and its computed value of the
'scroll-behavior' property is 'smooth'
behavior is smooth
...then follow these substeps:
Perform a smooth scroll of box to position.
Queue a task to run task, unless a task to run task is in the queue.
Repeat the previous step in a user-agent-defined interval while the smooth scroll is ongoing, as well as when the smooth scroll is completed (but not if it is aborted).
Otherwise, follow these substeps:
Perform an instant scroll of box to position.
Queue a task to run task, unless a task to run task is in the queue.
When a user agent is to perform a smooth scroll of a scrolling box box to position, it must update the scroll position of box in a user-agent-defined fashion over a user-agent-defined amount of time. When the scroll is completed, the scroll position of box must be position. The scroll can also be aborted, either by an algorithm or by the user.
When a user agent is to perform an instant scroll of a scrolling box box to position, it must update the scroll position of box to position.
To scroll to the beginning of the document for a document document, follow these steps:
Let viewport be the viewport that is associated with document.
Let position be the the scroll position viewport would have by aligning the beginning edges of the scrolling area with the beginning edges of viewport.
If position is the same as viewport's current scroll position, and viewport does not have an ongoing smooth scroll, abort these steps.
Let task be these steps:
Fire an event named scroll
that bubbles at document.
Perform a scroll of viewport to position, with the set of steps task, and document's root element as the associated element, if there is one, or null otherwise.
This algorithm is used when navigating to the #top
fragment identifier, as defined in HTML. [HTML]
When asked to normalize non-finite values for a value x,
if x is one of the three special floating point literal values
(Infinity
, -Infinity
or NaN
),
then x must be changed to the value 0
.
Return a new MediaQueryList
object,
associated with the Window
object, with
parsed media query list as its associated
media query list.
The screen
attribute must return the Screen
object
associated with the Window
object.
Accessing screen
through a WindowProxy
object might yield different
results when the Document
is navigated.
The moveTo(x, y) method must follow these steps:
Optionally, terminate these steps.
Normalize non-finite values for x and y.
Let target be the browsing context of the context object.
Let source be the responsible browsing context of the incumbent settings object.
If source is not allowed to resize and move target, terminate these steps.
Optionally, clamp x and y in a user-agent-defined manner so that the window does not move outside the available space.
Move target's window such that the window's top left corner is at coordinates (x, y) relative to the top left corner of the output device, measured in CSS pixels of target. The positive axes are rightward and downward.
The moveBy(x, y) method must follow these steps:
Optionally, terminate these steps.
Normalize non-finite values for x and y.
Let target be the browsing context of the context object.
Let source be the responsible browsing context of the incumbent settings object.
If source is not allowed to resize and move target, terminate these steps.
Optionally, clamp x and y in a user-agent-defined manner so that the window does not move outside the available space.
Move target's window x CSS pixels of target righward and y CSS pixels of target downward.
The resizeTo(x, y) method must follow these steps:
Optionally, terminate these steps.
Normalize non-finite values for x and y.
Let target be the browsing context of the context object.
Let source be the responsible browsing context of the incumbent settings object.
If source is not allowed to resize and move target, terminate these steps.
Optionally, clamp x and y in a user-agent-defined manner so that the window does not get too small or bigger than the available space.
Resize target's window by moving its right and bottom edges such that the distance between the left and right edges of the viewport are x CSS pixels of target and the distance between the top and bottom edges of the viewport are y CSS pixels of target.
Optionally, move target's window in a user-agent-defined manner so that it does not grow outside the available space.
The resizeBy(x, y) method must follow these steps:
Optionally, terminate these steps.
Let target be the browsing context of the context object.
Let source be the responsible browsing context of the incumbent settings object.
If source is not allowed to resize and move target, terminate these steps.
Optionally, clamp x and y in a user-agent-defined manner so that the window does not get too small or bigger than the available space.
Resize target's window by moving its right edge x CSS pixels of target righward and its bottom edge y CSS pixels of target downward.
Optionally, move target's window in a user-agent-defined manner so that it does not grow outside the available space.
A browsing context A is allowed to resize and move a browsing context B if all the following conditions are met:
B is an auxiliary browsing context that was created by a script (as opposed to by an action of the user).
A is familiar with B.
The innerWidth
attribute must return the viewport width including the size of a rendered
scroll bar (if any), or zero if there is no viewport.
The following snippet shows how to obtain the width of the viewport:
var viewportWidth = innerWidth
The innerHeight
attribute must return the viewport height including the size of a rendered
scroll bar (if any), or zero if there is no viewport.
The scrollX
attribute attribute must return the x-coordinate, relative to the initial containing
block origin, of the left of the viewport, or zero if there is no viewport.
The pageXOffset
attribute must return the value returned by the
scrollX
attribute.
The scrollY
attribute attribute must return the y-coordinate, relative to the initial containing
block origin, of the top of the viewport, or zero if there is no viewport.
The pageYOffset
attribute must return the value returned by the
scrollY
attribute.
When the scroll()
method is invoked these
steps must be run:
If invoked with one argument, follow these substeps:
Let options be the argument.
Let x be the value of the left
dictionary member of options, if present, or the viewport's current scroll position on the x axis otherwise.
Let y be the value of the top
dictionary member of options, if present, or the viewport's current scroll position on the y axis otherwise.
If invoked with two arguments, follow these substeps:
Let options be null converted to a ScrollToOptions
dictionary. [WEBIDL]
Let x and y be the arguments, respectively.
Normalize non-finite values for x and y.
If there is no viewport, abort these steps.
Let viewport width be the width of the viewport excluding the width of the scroll bar, if any.
Let viewport height be the height of the viewport excluding the height of the scroll bar, if any.
Let x be max(0, min(x, viewport scrolling area width - viewport width)).
Let x be min(0, max(x, viewport width - viewport scrolling area width)).
Let y be max(0, min(y, viewport scrolling area height - viewport height)).
Let y be min(0, max(y, viewport height - viewport scrolling area height)).
Let position be the scroll position the viewport would have by aligning the x-coordinate x of the viewport scrolling area with the left of the viewport and aligning the y-coordinate y of the viewport scrolling area with the top of the viewport.
If position is the same as the viewport's current scroll position, and the viewport does not have an ongoing smooth scroll, abort these steps.
Let task be these steps:
Fire an event named scroll
that bubbles at the
Document
object.
Perform a scroll of the viewport to position, with the set of steps task, and the
Document
's root element as the associated element, if there is one, or null otherwise, and the scroll behavior being the
value of the behavior
dictionary member of options.
When the scrollTo()
method is invoked, the
user agent must act as if the scroll()
method was invoked with the same arguments.
When the scrollBy()
method is invoked, the
user agent must run these steps:
If invoked with two arguments, follow these substeps:
Let options be null converted to a ScrollToOptions
dictionary. [WEBIDL]
Let x and y be the arguments, respectively.
Normalize non-finite values for x and y.
Let the left
dictionary member of options have the value x.
Let the top
dictionary member of options have the value y.
Add the value of scrollX
to the left
dictionary member.
Add the value of scrollY
to the top
dictionary member.
Act as if the scroll()
method was invoked with
options as the only argument.
The screenX
attribute must return the x-coordinate,
relative to the origin of the screen of the output device, of the left of
the client window as number of pixels, or zero if there is no such
thing.
The screenY
attribute must return the y-coordinate,
relative to the origin of the screen of the output device, of the top of
the client window as number of pixels, or zero if there is no such
thing.
The outerWidth
attribute must return the width of the
client window. If there is no client window this
attribute must return zero.
The outerHeight
attribute must return the height of the
client window. If there is no client window this
attribute must return zero.
The devicePixelRatio
attribute must return the result of the following algorithm:
If there is no output device, return 1 and abort these steps.
Let CSS pixel size be the size of a CSS pixel at the current page zoom scale factor and at a pinch zoom scale factor of 1.0.
Let device pixel size be the vertical size of a device pixel of the output device.
Return the result of dividing CSS pixel size by device pixel size.
open()
methodHTML defines the open()
method but has no defined effect for the third argument, features.
[HTML]
This specification defines the effect of the features argument for user agents that do not opt to ignore it, as follows:
If the method does not result in a new auxiliary browsing context being created, terminate these steps.
Let target be the new auxiliary browsing context.
Let tokens be the result of splitting features on commas.
Let parsed features be a new empty dictionary.
Token loop: For each token token in tokens, follow these substeps:
Let input be token.
Let position point at the first character of input.
Collect a sequence of characters that are not space
characters nor "=
" (U+003D). Let name be the collected characters, converted to ASCII
lowercase.
If name is in parsed features or if name is not a supported open()
feature name,
continue token loop.
If the character at position is not "=
" (U+003D), continue token loop.
Advance position by one.
If position is past the end of input, continue token loop.
Collect a sequence of characters that are any characters. Let raw value be the collected characters.
Let value be the result of invoking the rules for parsing integers on raw value.
If value is an error, continue token loop.
Set name in parsed features to value.
If left
is present in parsed features, follow these substeps:
Let x be the value of left
.
Optionally, clamp x in a user-agent-defined manner so that the window does not move outside the available space.
Optionally, move target's window such that the window's left edge is at the horizontal coordinate x relative to the left edge of the output device, measured in CSS pixels of target. The positive axis is rightward.
If top
is present in parsed features, follow these substeps:
Let y be the value of top
.
Optionally, clamp y in a user-agent-defined manner so that the window does not move outside the available space.
Optionally, move target's window such that the window's top edge is at the vertical coordinate y relative to the top edge of the output device, measured in CSS pixels of target. The positive axis is downward.
If width
is present in parsed features, follow these substeps:
Let x be the value of width
.
Optionally, clamp x in a user-agent-defined manner so that the window does not get too small or bigger than the available space.
Optionally, size target's window by moving its right edge such that the distance between the left and right edges of the viewport are x CSS pixels of target.
Optionally, move target's window in a user-agent-defined manner so that it does not grow outside the available space.
If height
is present in parsed features, follow these substeps:
Let y be the value of height
.
Optionally, clamp y in a user-agent-defined manner so that the window does not get too small or bigger than the available space.
Optionally, size target's window by moving its bottom edge such that the distance between the top and bottom edges of the viewport are y CSS pixels of target.
Optionally, move target's window in a user-agent-defined manner so that it does not grow outside the available space.
A supported open()
feature name is one of the following:
The width of the viewport.
The height of the viewport.
The left position of the window.
The top position of the window.
MediaQueryList
InterfaceA MediaQueryList
object has an associated media query list set on creation.
A MediaQueryList
object has an associated media which is the
serialized form of the associated media query list.
A MediaQueryList
object has an associated matches state which is
true if the associated media query list matches the state of the rendered Document
, and false otherwise.
If the associated media query list changes in evaluation, the user agent must queue a task to run these steps:
Let target be the MediaQueryList
object.
Let event be a new event
using the MediaQueryListEvent
interface,
with its type
attribute initialized to change
,
its isTrusted
attribute initialized to true,
its media
attribute initialized to target's media,
and its matches
attribute initialized to target's matches state.
Dispatch event to target.
A simple piece of code that detects changes in the orientation of the viewport can be written as follows:
function handleOrientationChange(event) { if(event.matches) // landscape … else … } var mql = matchMedia("(orientation:landscape)") mql.onchange = handleOrientationChange
interface MediaQueryList : EventTarget { readonly attribute DOMString media; readonly attribute boolean matches; void addListener(EventListener? listener); void removeListener(EventListener? listener); attribute EventHandler onchange; };
The media
attribute must return
the associated media.
The matches
attribute must return
the associated matches state.
The addListener(listener)
method must run these steps:
If listener is null, terminate these steps.
Append an event listener
to the associated list of
event listeners with type
set to change
, callback set to listener, and
capture set to false, unless there
already is an event listener in
that list with the same type, callback, and capture.
The removeListener(listener)
method must run these steps:
Remove an event listener
from the associated list of
event listeners, whose
type is change
, callback is listener, and
capture is false.
This specification initially had a custom callback mechanism with addListener
and
removeListener
, and the callback was invoked with the associated media query list as argument.
Now the normal event mechanism is used instead.
For backwards compatibility, the addListener
and removeListener
methods
are basically aliases for addEventListener
and removeEventListener
, respectively,
and the change
event masquerades as a MediaQueryList
.
The following are the event handlers
(and their corresponding event handler event types) that must be supported,
as event handler IDL attributes, by all objects implementing the MediaQueryList
interface:
| Event handler | Event handler event type |
|---|---|
| onchange | change
|
[Constructor(DOMString type, optional MediaQueryListEventInit eventInitDict)] interface MediaQueryListEvent : Event { readonly attribute DOMString media; readonly attribute boolean matches; }; dictionary MediaQueryListEventInit : EventInit { DOMString media = ""; boolean matches = false; };
The media
attribute must return the value it was initialized to.
The matches
attribute must return the value it was initialized to.
Screen
InterfaceAs its name suggests, the Screen
interface represents information about the screen of the output device.
interface Screen { readonly attribute double availWidth; readonly attribute double availHeight; readonly attribute double width; readonly attribute double height; readonly attribute unsigned long colorDepth; readonly attribute unsigned long pixelDepth; };
The availWidth
attribute must return the available width of the rendering surface of the output device,
in CSS pixels.
The availHeight
attribute must return the available height of the rendering surface of the output
device, in CSS pixels.
The width
attribute must return the width of the output device, in CSS pixels.
The height
attribute must return the height of the output device, in CSS pixels.
The colorDepth
attribute must return 24.
The pixelDepth
attribute must return 24.
The colorDepth
and pixelDepth
attributes are useless but are
included for compatibility.
Document
Interfacepartial interface Document { Element? elementFromPoint(double x, double y); sequence<Element> elementsFromPoint(double x, double y); CaretPosition? caretPositionFromPoint(double x, double y); };
The elementFromPoint(x, y)
method must follow these steps:
If either argument is negative, x is greater than the viewport width excluding the size of a rendered scroll bar (if any), or y is greater than the viewport height excluding the size of a rendered scroll bar (if any), or there is no viewport associated with the document, return null and terminate these steps.
If there is a layout box in the viewport that would be a target for hit testing at coordinates x,y, when applying the transforms that apply to the descendants of the viewport, return the associated element and terminate these steps.
If the document has a root element, return the root element and terminate these steps.
Return null.
The elementFromPoint()
method does not necessarily return the top-most painted element. For
instance, an element can be excluded from being a target for hit testing by using the 'pointer-events' CSS property.
The elementsFromPoint(x, y)
method must follow these steps:
Let sequence be a new empty sequence.
If either argument is negative, x is greater than the viewport width excluding the size of a rendered scroll bar (if any), or y is greater than the viewport height excluding the size of a rendered scroll bar (if any), or there is no viewport associated with the document, return sequence and terminate these steps.
For each layout box in the viewport, in paint order, starting with the topmost box, that would be a target for hit testing at coordinates x,y even if nothing would be overlapping it, when applying the transforms that apply to the descendants of the viewport, append the associated element to sequence.
If the document has a root element, and the last item in sequence is not the root element, append the root element to sequence.
Return sequence.
The caretPositionFromPoint(x, y)
method must return the
result of running these steps:
If there is no viewport associated with the document, return null.
If either argument is negative, x is greater than the viewport width excluding the size of a rendered scroll bar (if any), y is greather than the viewport height excluding the size of a rendered scroll bar (if any) return null.
If at the coordinates x,y in the viewport no text insertion point indicator would have been inserted when applying the transforms that apply to the descendants of the viewport, return null.
If at the coordinates x,y in the viewport a text insertion point indicator would have been inserted in a text entry widget which is also a replaced element, when applying the transforms that apply to the descendants of the viewport, return a caret position with its properties set as follows:
The node corresponding to the text entry widget.
The amount of 16-bit units to the left of where the text insertion point indicator would have inserted.
null
Otherwise, return a caret position where the
caret range is a collapsed
Range
object for the position
where the text insertion point indicator would have been inserted when applying the transforms that apply to the descendants of the
viewport, and the other properties are set as follows:
The startContainer
of the caret range.
The startOffset
of
the caret range.
The specifics of hit testing are out of scope of this
specification and therefore the exact details of
elementFromPoint()
and
caretPositionFromPoint()
are therefore too. Hit testing will hopefully be defined in a future
revision of CSS or HTML.
CaretPosition
InterfaceA caret position gives the position of a text insertion point indicator. It always has an associated
caret node, caret offset, and caret range. It is represented by a CaretPosition
object.
interface CaretPosition { readonly attribute Node offsetNode; readonly attribute unsigned long offset; DOMRect? getClientRect(); };
The offsetNode
attribute must return the caret node.
The offset
attribute must return the caret offset.
The getClientRect()
method must follow these steps, aborting on the first step that
returns a value:
If caret range is not null:
Let list be the result of invoking the
getClientRects()
method on the
range.
If list is empty, return null.
Return the DOMRect
object in list at index 0.
If caret node is a text entry widget that is a replaced element,
and that is in the document, return a DOMRect
object for the caret
in the widget as represented by the caret offset value. The transforms that apply to the element and its ancestors are
applied.
Return null.
Element
Interfaceenum ScrollLogicalPosition { "start", "end" }; dictionary ScrollIntoViewOptions : ScrollOptions { ScrollLogicalPosition block = "start"; }; partial interface Element { DOMRectList getClientRects(); DOMRect getBoundingClientRect(); void scrollIntoView(); void scrollIntoView((boolean or object) arg); void scroll(optional ScrollToOptions options); void scroll(unrestricted double x, unrestricted double y); void scrollTo(optional ScrollToOptions options); void scrollTo(unrestricted double x, unrestricted double y); void scrollBy(optional ScrollToOptions options); void scrollBy(unrestricted double x, unrestricted double y); attribute unrestricted double scrollTop; attribute unrestricted double scrollLeft; readonly attribute double scrollWidth; readonly attribute double scrollHeight; readonly attribute double clientTop; readonly attribute double clientLeft; readonly attribute double clientWidth; readonly attribute double clientHeight; };
The getClientRects()
method, when invoked, must return the result of the following algorithm:
If the element on which it was invoked does not have an associated
layout box return an empty DOMRectList
object and stop
this algorithm.
If the element has an associated SVG layout box return a
DOMRectList
object containing a single
DOMRect
object that describes the bounding box of the
element as defined by the SVG specification, applying the transforms that apply to the element and its ancestors.
Return a DOMRectList
object containing a list of
DOMRect
objects in content order describing the bounding border
boxes (including those with a height or width of zero) with the
following constraints:
Apply the transforms that apply to the element and its ancestors.
If the element on which the method was invoked has a computed value for the 'display' property of 'table' or 'inline-table' include both the table box and the caption box, if any, but not the anonymous container box.
Replace each anonymous block box with its child box(es) and repeat this until no anonymous block boxes are left in the final list.
The getBoundingClientRect()
method, when invoked, must return the result of the following
algorithm:
Let list be the result of invoking
getClientRects()
on the
same element this method was invoked on.
If the list is empty return a DOMRect
object whose x
,
y
,
width
and
height
members are zero.
Otherwise, return a DOMRect
object describing the
smallest rectangle that includes the first rectangle in list
and all of the remaining rectangles of which the height or width is not
zero.
The following snippet gets the dimensions of the first
div
element in a document:
var example = document.getElementsByTagName("div")[0].getBoundingClientRect(); var exampleWidth = example.width; var exampleHeight = example.height;
The scrollIntoView(arg)
method must run these steps:
Let options be null.
If arg is an object, let options be arg.
Convert options to a ScrollIntoViewOptions
dictionary. [WEBIDL]
If arg is false, let the block
dictionary member of options have the value "end
".
If the element does not have any associated layout box terminate these steps.
Scroll the element into view
with the align to top flag set if options block
dictionary member has the value "start
",
and the scroll behavior being the value of the behavior
dictionary member of options.
Optionally perform some other action that brings the element to the user's attention.
The scroll()
method must run these steps:
If invoked with one argument, follow these substeps:
Let options be the argument.
Let x be the value of the left
dictionary member of options, if present, or the element's current scroll position on the x axis otherwise.
Let y be the value of the top
dictionary member of options, if present, or the element's current scroll position on the y axis otherwise.
If invoked with two arguments, follow these substeps:
Let options be null converted to a ScrollToOptions
dictionary. [WEBIDL]
Let x and y be the arguments, respectively.
Normalize non-finite values for x and y.
Let the left
dictionary member of options have the value x.
Let the top
dictionary member of options have the value y.
If the element is the root element and the Document
is in
quirks mode, terminate these steps.
If the element is the root element invoke
scroll()
with scrollX
as first
argument and y as second argument, and terminate these steps.
If the element is the HTML body
element,
the Document
is in quirks mode, and the element
does not have an associated scrolling box, invoke
scroll()
with
options as the only argument, and
terminate these steps.
If the element does not have any associated CSS layout box, the element has no associated scrolling box, or the element has no overflow, terminate these steps.
Scroll the element to
x,y, with the scroll behavior being the value of the behavior
dictionary member of options.
When the scrollTo()
method is invoked, the
user agent must act as if the scroll()
method was invoked with the same arguments.
When the scrollBy()
method is invoked, the
user agent must run these steps:
If invoked with two arguments, follow these substeps:
Let options be null converted to a ScrollToOptions
dictionary. [WEBIDL]
Let x and y be the arguments, respectively.
Normalize non-finite values for x and y.
Let the left
dictionary member of options have the value x.
Let the top
dictionary member of options have the value y.
Add the value of scrollLeft
to the left
dictionary member.
Add the value of scrollTop
to the top
dictionary member.
Act as if the scroll()
method was invoked with
options as the only argument.
The scrollTop
attribute, on getting, must return the result of running these steps:
If the element is the root element and the Document
is in
quirks mode, return zero and terminate these steps.
If the element is the root element return the value of
scrollY
.
If the element is the HTML body
element,
the Document
is in quirks mode, and the element does not have
an associated scrolling box, return the value of
scrollY
.
If the element does not have any associated CSS layout box, return zero and terminate these steps.
Return the y-coordinate of the scrolling area at the alignment point with the top of the padding edge of the element.
When setting the scrollTop
attribute these steps must be run:
Let y be the given value.
Normalize non-finite values for y.
If the element is the root element and the Document
is in
quirks mode, terminate these steps.
If the element is the root element invoke
scroll()
with scrollX
as first
argument and y as second argument, and terminate these steps.
If the element is the HTML body
element,
the Document
is in quirks mode, and the element
does not have an associated scrolling box, invoke
scroll()
with
scrollX
as first
argument and y as second argument, and
terminate these steps.
If the element does not have any associated CSS layout box, the element has no associated scrolling box, or the element has no overflow, terminate these steps.
Scroll the element to
scrollLeft
,y, with the scroll behavior being auto
.
The scrollLeft
attribute, on getting, must return the result of running these steps:
If the element is the root element and the Document
is in
quirks mode, return zero and terminate these steps.
If the element is the root element return the value of
scrollX
.
If the element is the HTML body
element,
the Document
is in quirks mode, and the element does not have
an associated scrolling box, return the value of
scrollX
.
If the element does not have any associated CSS layout box, return zero and terminate these steps.
Return the x-coordinate of the scrolling area at the alignment point with the left of the padding edge of the element.
When setting the scrollLeft
attribute these steps must be run:
Let x be the given value.
Normalize non-finite values for x.
If the element is the root element and the Document
is in
quirks mode, terminate these steps.
If the element is the root element invoke
scroll()
with
x as first argument and scrollY
as second argument, and terminate these steps.
If the element is the HTML body
element,
the Document
is in quirks mode, and the element
does not have an associated scrolling box, invoke
scroll()
with
x as first argument and
scrollY
as second
argument, and terminate these steps.
If the element does not have any associated CSS layout box, the element has no associated scrolling box, or the element has no overflow, terminate these steps.
Scroll the element to
x,scrollTop
, with the scroll behavior being auto
.
The scrollWidth
attribute must return the result of running these steps:
Let viewport width be the width of the viewport excluding the width of the scroll bar, if any, or zero if there is no viewport.
If the element is the root element and the
Document
is not in
quirks mode
return max(viewport scrolling area width, viewport width).
If the element is the HTML body
element, the Document
is in
quirks mode and the element has no associated scrolling box,
return max(viewport scrolling area width, viewport width).
If the element does not have any associated CSS layout box return zero and terminate these steps.
Return the width of the element's scrolling area.
The scrollHeight
attribute must return the result of running these steps:
Let viewport height be the height of the viewport excluding the height of the scroll bar, if any, or zero if there is no viewport.
If the element is the root element and the
Document
is not in
quirks mode
return max(viewport scrolling area height, viewport height).
If the element is the HTML body
element, the Document
is in
quirks mode and the element has no associated scrolling box,
return max(viewport scrolling area height, viewport height).
If the element does not have any associated CSS layout box return zero and terminate these steps.
Return the height of the element's scrolling area.
The clientTop
attribute must run these steps:
If the element has no associated CSS layout box or if the CSS layout box is inline, return zero.
Return the computed value of the 'border-top-width' property plus the height of any scrollbar rendered between the top padding edge and the top border edge, ignoring any transforms that apply to the element and its ancestors.
The clientLeft
attribute must run these steps:
If the element has no associated CSS layout box or if the CSS layout box is inline, return zero.
Return the computed value of the 'border-left-width' property plus the width of any scrollbar rendered between the left padding edge and the left border edge, ignoring any transforms that apply to the element and its ancestors.
The clientWidth
attribute must run these steps:
If the element has no associated CSS layout box or if the CSS layout box is inline, return zero.
If the element is the root element and the element's document is not in quirks mode, or
if the element is the HTML body
element and the element's document is in
quirks mode, return the viewport width excluding the size of a rendered scroll bar
(if any).
Return the width of the padding edge excluding the width of any rendered scrollbar between the padding edge and the border edge, ignoring any transforms that apply to the element and its ancestors.
The clientHeight
attribute must run these steps:
If the element has no associated CSS layout box or if the CSS layout box is inline, return zero.
If the element is the root element and the element's document is not in quirks mode, or
if the element is the HTML body
element and the element's document is in
quirks mode, return the viewport height excluding the size of a rendered scroll
bar (if any).
Return the height of the padding edge excluding the height of any rendered scrollbar between the padding edge and the border edge, ignoring any transforms that apply to the element and its ancestors.
getClientRects()
and
getBoundingClientRect()
methodsThe getClientRects()
and getBoundingClientRect()
methods provide information about the position of the border box edges of
an element relative to the viewport. The objects these methods return
must be static. That is, changes to the underlying
document are not reflected in the objects.
Element
Scrolling MembersTo scroll an element into view element, optionally with an align to top flag set, and optionally with a scroll behavior
behavior (which is auto
if omitted), means to run these steps for each ancestor element or viewport that establishes
a scrolling box scrolling box, in order of innermost to outermost scrolling box:
If the Document
associated
with element is not same origin with the
Document
associated with the element or
viewport associated with box, terminate these
steps.
Let element bounding border box be the box that the return value of invoking
getBoundingClientRect()
on element represents.
Let scrolling box edge A be the beginning edge in the block flow direction of scrolling box, and let element edge A be element bounding border box's edge on the same physical side as that of scrolling box edge A.
Let scrolling box edge B be the ending edge in the block flow direction of scrolling box, and let element edge B be element bounding border box's edge on the same physical side as that of scrolling box edge B.
Let scrolling box edge C be the beginning edge in the inline base direction of scrolling box, and let element edge C be element bounding border box's edge on the same physical side as that of scrolling box edge C.
Let scrolling box edge D be the ending edge in the inline base direction of scrolling box, and let element edge D be element bounding border box's edge on the same physical side as that of box edge D.
Let element width be the distance between element edge C and element edge D.
Let scrolling box width be the distance between scrolling box edge C and scrolling box edge D.
Let position be the scroll position scrolling box would have by following these steps:
If the align to top flag is set align element edge A with scrolling box edge A.
Otherwise, the align to top flag is not set; align element edge B with scrolling box edge B.
Do nothing.
Align element edge C with scrolling box edge C.
Align element edge D with scrolling box edge D.
If position is the same as scrolling box's current scroll position, and scrolling box does not have an ongoing smooth scroll, abort these steps.
Let associated element be the element.
Let task be these steps:
Fire an event
named scroll
at associated element.
Let associated element be the Document
's root element, if there is one, or null otherwise.
Let task be these steps:
Fire an event
named scroll
that bubbles at the
Document
object associated with the viewport.
Perform a scroll of scrolling box to position, with the set of steps task, associated element as the associated element and behavior as the scroll behavior.
To scroll an element element to x,y optionally with a scroll behavior behavior (which is
auto
if omitted) means to:
Let box be element's associated scrolling box.
Let x be max(0, min(x, element scrolling area width - element padding edge width)).
Let x be min(0, max(x, element padding edge width - element scrolling area width)).
Let y be max(0, min(y, element scrolling area height - element padding edge height)).
Let y be min(0, max(y, element padding edge height - element scrolling area height)).
Let position be the scroll position box would have by aligning scrolling area x-coordinate x with the left of box and aligning scrolling area y-coordinate y with the top of box.
If position is the same as box's current scroll position, and box does not have an ongoing smooth scroll, abort these steps.
Let task be these steps:
Fire an event named
scroll
at the element.
Perform a scroll of box to position, with the set of steps task, element as the associated element and behavior as the scroll behavior.
HTMLElement
Interfacepartial interface HTMLElement { readonly attribute Element? offsetParent; readonly attribute double offsetTop; readonly attribute double offsetLeft; readonly attribute double offsetWidth; readonly attribute double offsetHeight; };
The offsetParent
attribute must return the result of running these steps:
If any of the following holds true return null and terminate this algorithm:
body
element.Return the nearest ancestor element of the element for which at least one of the following is true and terminate this algorithm if such an ancestor is found:
body
element.td
, th
, or table
.Return null.
The offsetTop
attribute must return the result of running these steps:
If the element is the HTML body
element
or does not have any associated CSS layout box return zero and terminate
this algorithm.
If the offsetParent
of the element is null return the
y-coordinate of the top border edge of the first
CSS layout box associated with the element, relative to the
initial containing block origin, ignoring any transforms that apply to the element and its ancestors, and terminate this
algorithm.
Return the result of subtracting the y-coordinate of the top
padding edge of the first CSS layout box associated with
the offsetParent
of the element from the y-coordinate of
the top border edge of the first CSS layout box associated
with the element, relative to the initial containing block
origin, ignoring any transforms that apply to the element and its ancestors.
An inline element that consists of multiple line boxes will only have its first CSS layout box considered.
The offsetLeft
attribute must return the result of running these steps:
If the element is the HTML body
element or does not have any associated CSS layout box return zero
and terminate this algorithm.
If the offsetParent
of the element is null return the
x-coordinate of the left border edge of the first
CSS layout box associated with the element, relative to the
initial containing block origin, , ignoring any transforms that apply to the element and its ancestors, and terminate this
algorithm.
Return the result of subtracting the x-coordinate of the left
padding edge of the first CSS layout box associated with
the offsetParent
of the element from the x-coordinate of
the left border edge of the first CSS layout box associated
with the element, relative to the initial containing block
origin, ignoring any transforms that apply to the element and its ancestors.
The offsetWidth
attribute must return the result of running these steps:
If the element does not have any associated CSS layout box return zero and terminate this algorithm.
Return the border edge width of the first CSS layout box associated with the element, ignoring any transforms that apply to the element and its ancestors.
The offsetHeight
attribute must return the result of running these steps:
If the element does not have any associated CSS layout box return zero and terminate this algorithm.
Return the border edge height of the first CSS layout box associated with the element, ignoring any transforms that apply to the element and its ancestors.
HTMLImageElement
Interfacepartial interface HTMLImageElement { readonly attribute double x; readonly attribute double y; };
The x
attribute, on getting, must return the x-coordinate of the left border edge of the
first CSS layout box associated with the element, relative to the initial containing block origin, ignoring any
transforms that apply to the element and its ancestors, or zero if there is no CSS layout box.
The y
attribute, on getting, must return the y-coordinate of the top border edge of the
first CSS layout box associated with the element, relative to the initial containing block origin, ignoring any
transforms that apply to the element and its ancestors, or zero if there is no CSS layout box.
Range
InterfaceThe objects the methods described below return must be static.
partial interface Range { DOMRectList getClientRects(); DOMRect getBoundingClientRect(); };
The getClientRects()
method, when invoked, must return an empty
DOMRectList
object if the range is not in the document and
otherwise a DOMRectList
object containing a list of
DOMRect
objects in content order that matches the
following constraints:
getClientRects()
on the
element.Text
node selected or partially selected by the
range (including when the boundary-points are identical), include a
DOMRect
object (for the part that is selected, not the
whole line box). The bounds of these DOMRect
objects are
computed using font metrics; thus, for horizontal writing, the vertical
dimension of each box is determined by the font ascent and descent, and
the horizontal dimension by the text advance width. The transforms that apply to the ancestors are applied.
The getBoundingClientRect()
method, when invoked, must return the result of the following
algorithm:
Let list be the result of invoking
getClientRects()
on the
same range this method was invoked on.
If list is empty return a
DOMRect
object whose
x
,
y
,
width
and
height
members are zero.
Otherwise, return a DOMRect
object describing the
smallest rectangle that includes the first rectangle in list
and all of the remaining rectangles of which the height or width is not
zero.
MouseEvent
InterfaceThe object IDL fragment redefines some members.
The screenY
attribute must return the y-coordinate of
the position where the event occurred relative to the origin of the
screen.
The pageX
attribute must follow these steps:
If the event's dispatch flag is set, return the horizontal coordinate of the position where the event occurred relative to the origin of the initial containing block and terminate these steps.
Let offset be the value of the scrollX
attribute of the event's associated
Window
object, if there is one, or zero otherwise.
Return the sum of offset and the value of the event's clientX
attribute.
The pageY
attribute must follow these steps:
If the event's dispatch flag is set, return the vertical coordinate of the position where the event occurred relative to the origin of the initial containing block and terminate these steps.
Let offset be the value of the scrollX
attribute of the event's associated
Window
object, if there is one, or zero otherwise.
Return the sum of offset and the value of the event's clientY
attribute.
The clientX
attribute must return the x-coordinate of
the position where the event occurred relative to the origin of the
viewport.
The clientY
attribute must return the y-coordinate of
the position where the event occurred relative to the origin of the
viewport.
The x
attribute must return the value of clientX
.
The y
attribute must return the value of clientY
.
The offsetX
attribute must follow these steps:
If the event's dispatch flag is set, return the x-coordinate of the position where the event occurred relative to the origin of the padding edge of the target node, ignoring the transforms that apply to the element and its ancestors, and terminate these steps.
Return the value of the event's pageX
attribute.
The offsetY
attribute must follow these steps:
If the event's dispatch flag is set, return the y-coordinate of the position where the event occurred relative to the origin of the padding edge of the target node, ignoring the transforms that apply to the element and its ancestors, and terminate these steps.
Return the value of the event's pageY
attribute.
GeometryUtils
Interfaceenum CSSBoxType { "margin", "border", "padding", "content" }; dictionary BoxQuadOptions { CSSBoxType box = "border"; GeometryNode relativeTo; }; dictionary ConvertCoordinateOptions { CSSBoxType fromBox = "border"; CSSBoxType toBox = "border"; }; [NoInterfaceObject] interface GeometryUtils { sequence<DOMQuad> getBoxQuads(optional BoxQuadOptions options); DOMQuad convertQuadFromNode(DOMQuad quad, GeometryNode from, optional ConvertCoordinateOptions options); DOMQuad convertRectFromNode(DOMRectReadOnly rect, GeometryNode from, optional ConvertCoordinateOptions options); DOMPoint convertPointFromNode(DOMPointInit point, GeometryNode from, optional ConvertCoordinateOptions options); }; Text implements GeometryUtils; Element implements GeometryUtils; PseudoElement implements GeometryUtils; Document implements GeometryUtils; typedef (Text or Element or PseudoElement or Document) GeometryNode;
The getBoxQuads(options)
method must run the following steps:
...
The convertQuadFromNode(quad, from, options)
method
must run the following steps:
...
The convertRectFromNode(rect, from, options)
method
must run the following steps:
...
The convertPointFromNode(point, from, options)
method must run the following steps:
...
Whenever a viewport has its width or height changed (e.g. as a result of the user resizing the browser window, or changing the page
zoom scale factor, or an iframe
element's dimensions are changed), the user agent must queue a task
to fire an event event named
resize
at the Window
object associated with that
viewport. If such a resize is ongoing over a period of time, the user agent must queue that
task at a user-agent-defined interval while the resize is ongoing.
Whenever a viewport gets scrolled in response to user interaction, the user agent must queue a task to
fire an event named
scroll
that bubbles at the Document
object associated with that viewport. If such a scroll is
ongoing over a period of time, the user agent must queue that task at a user-agent-defined interval
while the scroll is ongoing.
Whenever an element gets scrolled in response to user interaction, the user agent must queue a task to
fire an event named
scroll
at the element. If such a scroll is ongoing over a period of time, the user agent must
queue that task at a user-agent-defined interval while the scroll is ongoing.
The features in this section should be moved to some other specification.
Name: scroll-behavior Value: auto | smooth Initial: auto Applies to: scrolling boxes Inherited: no Computed value: specified value Media: visual Animatable: no Canonical Order: per grammar
The 'scroll-behavior' property specifies the scrolling behavior for a scrolling box, when scrolling happens due to navigation or CSSOM scrolling APIs. Any other scrolls, e.g. those that are performed by the user, are not affected by this property. When this property is specified on the root element, it applies to the viewport instead.
The 'scroll-behavior' property of the HTML body
element is not propagated to the viewport.
The scrolling box is scrolled in an instant fashion.
The scrolling box is scrolled in a smooth fashion using a user-agent-defined timing function over a user-agent-defined period of time. User agents should follow platform convensions, if any.
User agents may ignore this property.
This section documents some of the changes between publications of this specification. This section is not exhaustive. Bug fixes and editorial changes are generally not listed.
moveTo()
, moveBy()
, resizeTo()
and
resizeBy()
methods are now defined.
innerWidth
et al now use the WebIDL type double
instead of long
.
devicePixelRatio
is now defined.
features
argument to window.open()
is now defined.
colorDepth
and pixelDepth
attributes of Screen
now
always return 24.
elementsFromPoint()
method of Element
is introduced.
ClientRect
has been renamed to DOMRect
and has moved to the Geometry specification.
[GEOMETRY]
resize
and scroll
events fire.
The editors would like to thank Alan Stearns, Alexey Feldgendler, Antonio Gomes, Björn Höhrmann, Dan Bates, David Vest, Elliott Sprehn, Garrett Smith, Henrik Andersson, Hallvord R. M. Steen, Kang-Hao Lu, Leif Arne Storset, Luiz Agostini, Maciej Stachowiak, Michael Dyck, Mike Wilson, Morten Stenshorne, Olli Pettay, Pavel Curtis, Peter-Paul Koch, Rachel Kmetz, Robert O'Callahan, Sam Weinig, Scott Johnson, Sebastian Zartner, Stewart Brodie, Sylvain Galineau, Tab Atkins, Tarquin Wilton-Jones, Thomas Moore, and Xiaomei Ji for their contributions to this document.
Special thanks to the Microsoft employees who first implemented many of the features specified in this draft, which were first widely deployed by the Windows Internet Explorer browser.